Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 148757 - cups obsoletes LPRng unconditionally
Summary: cups obsoletes LPRng unconditionally
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2005-02-15 12:26 UTC by Toby Blake
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 1.2.2-10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-11 17:05:33 UTC

Attachments (Terms of Use)

Description Toby Blake 2005-02-15 12:26:32 UTC
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):

How reproducible:

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

Additional info:

Comment 1 Tim Waugh 2005-02-15 12:32:13 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. :-(

Comment 2 Toby Blake 2005-02-15 12:44:14 UTC
Can you explain a bit more?  What are the effects of the cups RPM not
claiming to provide LPRng 3.8.15-3?

Comment 3 Tim Waugh 2005-02-15 13:03:27 UTC
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.

Comment 4 Toby Blake 2005-02-15 13:21:44 UTC
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?

Comment 5 Tim Waugh 2005-02-15 13:31:52 UTC
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

Comment 6 Toby Blake 2005-02-15 13:39:21 UTC
OK, thanks for letting me know.

Although I do still think this is a nasty bug, I at least know the
reasoning behind it.


Comment 7 Matthew Miller 2006-07-10 22:34:28 UTC
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!

Comment 8 Dominik 'Rathann' Mierzejewski 2006-08-11 15:12:51 UTC
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

Comment 9 Rex Dieter 2006-08-11 15:53:31 UTC
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.

Comment 10 Tim Waugh 2006-08-11 16:00:19 UTC
So I'll keep the 'Obsoletes: LPRng <= 3.8.15-3' line, and remove 'LPRng =
3.8.15-3' from Provides.  Is that right?

Comment 11 Rex Dieter 2006-08-11 16:10:08 UTC
Yeah, it's the Provides: that's the issue here.

Comment 12 Dominik 'Rathann' Mierzejewski 2006-08-11 19:14:01 UTC
Thanks! Will this fix appear in FC5, too?

Comment 13 Tim Waugh 2006-08-16 10:51:00 UTC
Yes, fixed in CVS from 1.2.2-1.7.

Note You need to log in before you can comment on or make changes to this bug.