Bug 148757
| Summary: | cups obsoletes LPRng unconditionally | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Toby Blake <toby> |
| Component: | cups | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dominik, mattdm, rdieter |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.2.2-10 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-11 17:05:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 150223 | ||
|
Description
Toby Blake
2005-02-15 12:26:32 UTC
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. |