This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 148757 - cups obsoletes LPRng unconditionally
cups obsoletes LPRng unconditionally
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: Reopened
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2005-02-15 07:26 EST by Toby Blake
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.2.2-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-11 13:05:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Toby Blake 2005-02-15 07:26:32 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:
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:
Comment 1 Tim Waugh 2005-02-15 07:32:13 EST
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 07:44:14 EST
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 08:03:27 EST
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 08:21:44 EST
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 08:31:52 EST
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).
Comment 6 Toby Blake 2005-02-15 08:39:21 EST
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
Comment 7 Matthew Miller 2006-07-10 18:34:28 EDT
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 11:12:51 EDT
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 11:53:31 EDT
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 12:00:19 EDT
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 12:10:08 EDT
Yeah, it's the Provides: that's the issue here.
Comment 12 Dominik 'Rathann' Mierzejewski 2006-08-11 15:14:01 EDT
Thanks! Will this fix appear in FC5, too?
Comment 13 Tim Waugh 2006-08-16 06:51:00 EDT
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.