conflict between xpdf and poppler-utils is not necessary

[chaos eternal]

Binary package hint: xpdf-utils

many core packages depends on poppler-utils while xpdf-utils conflict with poppler-utils.
so, when somebody install xpdf-utils, these core packages will be removed.

this is not necessary.

one suggestion is that using alternatives mechanisms to have xpdf-utils and poppler-utils co-exist in system.

xpdf-utils has some advantages while processing buggy pdfs.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xpdf-utils (not installed)
ProcVersionSignature: Ubuntu 2.6.32-27.49-generic 2.6.32.26+drm33.12
Uname: Linux 2.6.32-27-generic x86_64
Architecture: amd64
Date: Tue Jan 4 16:10:12 2011
ProcEnviron:
 LANGUAGE=zh_CN:zh:en_US:en
 PATH=(custom, user)
 LANG=zh_CN.utf8
 SHELL=/bin/bash
SourcePackage: xpdf

[Michael Gilbert (michael-s-gilbert)]

this is fixed in newer version where xpdf uses the poppler backend.

[Yitzchak Gale (gale-sefer)]

xpdf-utils cannot "use the poppler backend". poppler is a different project.
It started out years ago as a fork of xpdf. They made the unfortunate decision
to use the same exact names for their command-line utilities as are
used by xpdf, creating major headaches for all distribution frameworks.

By this time, xpdf and poppler have diverged, each with its own
advantages and disadvantages, as pointed out by OP. In addition, their
output is different, so programs that parse their output cannot be easily
ported from one to the other. I make heavy use of xpdf in my work.

It is a major error to take the package name "xpdf-utils" and suddenly
make it install programs from a totally different package instead,
effectively removing xpdf-util completely from Ubuntu.

In my opinion, xpdf-utils should not be removed from Ubuntu. It is a significant
component of a classic high-quality supported open source project.
Please immediately undo that "change" to xpdf-utils.

Regarding the dependency problem in this bug report: one approach
is to install the xpdf utilities with different names. E.g.,
pdftops => xpdf-pdftops, etc. That is the approach currently taken by MacPorts:
see http://trac.macports.org/ticket/17540

[Yitzchak Gale (gale-sefer)]

This seems to have been caused by an oversight in Debian
when they switched to poppler for rendering in the xpdf
viewer. I filed Debian bug #622343. Let's see how that goes.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622343

[Michael Gilbert (michael-s-gilbert)]

see debian bug report for detailed response. this is bug is not even related to the issue at hand.