Hi there! I cc:ed everyone who got in touch with this bug, please forgive me if you are no more interested in it.
I discovered this bug because of a dependency problem in cups: http://bugs.debian.org/557885 On Wed, 09 Jul 2008 18:01:40 +0200, W. Martin Borgert wrote: > If the two projects are forked, the code will diverge further. > Therefore the feature set and bugs will be different. Users may > want to use one or other command. So we will need alternatives. It seems that poppler-utils has already diverged too much from xpdf-utils and it is now impossible to rely on xpdf-utils for some features, like the -origpagesizes present only in poppler-utils' pdftops (option needed by cups). Moreover, Matt already discovered that xpdf-utils is missing pdftoppm, which is instead shipped by xpdf-reader: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409510#45 I filed the following IMHO obvious bugs to xpdf-reader and poppler-utils, respectively: http://bugs.debian.org/558020 http://bugs.debian.org/558021 For these reasons, I think that xpdf-utils should stop to Provides: poppler-utils, while the contrary should still be possible. Please note that I have not completely checked if all binaries from poppler-utils are compatible with the ones from xpdf-utils. However, if both packages are installed and managed through alternatives, AFAIK we will for sure have breakages for those packages not directly conflicting with xpdf-utils. Thus IMHO the alternatives are useless. Is there any reason to still keep xpdf-utils and not having it as a dummy package depending on poppler-utils? Thx, bye, Gismo / Luca
pgpb29Dw55O4h.pgp
Description: PGP signature
