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
pgpCCvswZfg6l.pgp
Description: PGP signature