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: Hi, This bug was also reported for RHEL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128024 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 upgraded). Version-Release number of selected component (if applicable): cups-1.1.22-0.rc1.8.4 How reproducible: Always 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 3. 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 Additional info:
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 upgrade process: something older (with LPRng as default) -> something newer (with CUPS as default) 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 place). 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 haven't).
OK, thanks for letting me know. Although I do still think this is a nasty bug, I at least know the reasoning behind it. Cheers Toby
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. Thank you!
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.