Red Hat Bugzilla – Bug 148757
cups obsoletes LPRng unconditionally
Last modified: 2007-11-30 17:11:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0
Description of problem:
This bug was also reported for RHEL:
The problem is that the spec file for cups has the following:
Provides: lpd lpr LPRng = 3.8.15-3
i.e. it claims to provide package LPRng version 3.8.15-3, which seems
to me to be a bug. Not only does cups not provide all the features of
LPRng (e.g. kerberised printing), but this stops the user from being
able to install LPRng alongside cups. Or more accurately, you can
install LPRng, but not upgrade it, as it then thinks that the cups rpm
should be removed (as it's package LPRng v3.8.15-3, which needs to be
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install LPRng rpm with alteratives code to let LPRng/cups coexist
2. bump version number of rpm and attempt to upgrade it
Actual Results: Upgrade of LPRng will fail with failed dependencies
(packages that require cups)
Expected Results: Upgrade of LPRng should work, without involving
cups at all
It's basically impossible to get this to work at the same time as
having upgrades from Red Hat Linux 9 do the right thing. :-(
Can you explain a bit more? What are the effects of the cups RPM not
claiming to provide LPRng 3.8.15-3?
When you upgrade from RHL9 to FC3 (say), you need to have LPRng replaced by CUPS
or else you'll lose all your queue information. 3.8.15-3 is the last version of
LPRng we shipped. Anaconda needs to know what package to install in place of
LPRng, and that needs to be done with Obsoletes/Provides.
Newer LPRng RPMs should be possible to *upgrade* to from cups, but to have both
installed at once would mean not having the Obsoletes/Provides tags, and that
would mean anaconda not adding CUPS to the package set on upgrade -- and that
would mean broken upgrade systems.
Hmm, so it seems that this is built-in to protect the following
something older (with LPRng as default) -> something newer (with CUPS
Is this the case?
Note that CUPS had already replaced LPRng in RHL9.
I don't quite understand your comment about "or else you'll lose all
your queue information" - cups and LPRng have different mechanisms for
providing queue information. What happens now in terms of queue
information if you upgrade, such that LPRng is replaced by CUPS? Is
it somehow transferred from LPRng to CUPS?
I have to say that I do think this is a bug in CUPS (in that it breaks
the upgrade of another package, irrespective of any criteria). Shall
I assume from your comments that it won't be fixed and I should just
patch my own cups rpm?
In RHL9, *both* LPRng and CUPS were shipped.
Yes, queue information is transferred over (if you used printtool in the first
It won't be fixed soon -- the only fix is to drop the Obsoletes/Provides, and
I'd rather wait until everyone who's going to upgrade has done so (and they
OK, thanks for letting me know.
Although I do still think this is a nasty bug, I at least know the
reasoning behind it.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
Can this be fixed now? I plan to submit LPRng 3.8.28 to Fedora Extras and I
can't since it'll break with cups providing LPRng. I don't think upgrades from
RH9 are an issue anymore. And LPRng can coexist with cups peacefully...
Small patch to fix this:
--- cups.spec.orig 2006-07-20 12:47:09.000000000 +0200
+++ cups.spec 2006-08-11 16:57:01.000000000 +0200
@@ -51,7 +51,7 @@
# Unconditionally obsolete LPRng so that upgrades work properly.
Obsoletes: lpd lpr LPRng <= 3.8.15-3
-Provides: lpd lpr LPRng = 3.8.15-3
+Provides: lpd lpr
BuildPrereq: pam-devel pkgconfig
BuildPrereq: gnutls-devel libacl-devel
Agreed, this should be reconsiderred. (A similar situation as this arose with
cyrus-imap and (uw-)imap (see bug #127448)
Tim, you can get the replacment you want by simply including
LPRng <= 3.8.15-3
The Provides shouldn't be necessary for that.
So I'll keep the 'Obsoletes: LPRng <= 3.8.15-3' line, and remove 'LPRng =
3.8.15-3' from Provides. Is that right?
Yeah, it's the Provides: that's the issue here.
Thanks! Will this fix appear in FC5, too?
Yes, fixed in CVS from 1.2.2-1.7.