[Pkg-cups-devel] Bug#557885: Bug#557885: cups: strictly Depends: on poppler-utils, no more xpdf-utils

[Luca Capello]

found 557885 1.4.2-2
notfound 557885 1.4.1-5
thanks

Hi Martin!

I have corrected the version in which this bug was found: since I have
not yet upgraded cups, the old one was automatically picked, sorry.

On Wed, 25 Nov 2009 08:39:10 +0100, Martin Pitt wrote:
> Luca Capello [2009-11-25  2:27 +0100]:
>> The latest uploaded version introduced a strict dependency on
>> poppler-utils >= 0.12.  Previously, the dependency was "poppler-utils |
>> xpdf-utils" and indeed I could have cups installed with xpdf-utils.  Now
>> this is not possible anymore and the debian/changelog does not contain
>> any useful information about that.
>
> It's in 1.3.10-3:
>
>   * debian/control: Drop ghostscript build dependency again, pdftops filter
>     uses poppler again. Also Drop alternative xpdf-utils build dependency,
>     since configure now checks for poppler's pdftops capabilities.

These are build, not runtime dependencies.  And indeed the version I
have installed, 1.4.1-5, works with xpdf-utils as well:
=====
gismo:~# dpkg -s cups
Package: cups
Status: install ok installed
[...]
Version: 1.4.1-5
Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16),
[...]
  libpoppler4,
[...]
  poppler-utils | xpdf-utils,
[...]
gismo:~#
=====

> Also, poppler-utils' pdftops supports -origpagesizes which is required
> for correct handling of mixed portrait/landscape documents.

I was always under the impression that poppler was nothing more than a
fork of xpdf, while it seems that it is now gone beyond that.  This
probably means that both poppler- and xpdf-utils should stop to
Provides: each others, this is #409510:

  http://bugs.debian.org/409510

Or, if poppler-utils is 100% compatible with xpdf-utils (according to
your statement the contrary is already not true), only xpdf-utils is at
fault here and it should stop to Provides: poppler-utils.

>> Given that xpdf-utils Provides: poppler-utils, this could also be a bug
>> in the package manager or in the poppler- or xpdf-utils packages, since:
>> 
>> - `apt-get upgrade` on my sid keeps cups on hold, since it requires
>>   poppler-utils which Conflicts: with xpdf-utils, but install all the
>>   other cups* packages
>
> Hm, not sure how to fix that; perhaps an additional Breaks:
> xpdf-utils?

While I think that this should be the correct way to fix this with the
current poppler- and xpdf-utils situation (they Provides: each others),
however if they become coinstallable through alternatives (again,
#409510) it will be impossible to know which pdftops is the default,
thus cups will behave differently in one case or the other.  This is why
I think that the easiest and future-proof solution would be to
Conflicts: with xpdf-utils.

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20091125/f97c7aa6/attachment.pgp>