Bug 128024 - cups obsoletes LPRng unconditionally
Summary: cups obsoletes LPRng unconditionally
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-16 14:12 UTC by Jonathan Reed
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: 1.1.17-13.3.16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-15 11:38:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jonathan Reed 2004-07-16 14:12:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)

Description of problem:
Cups appears to obsolete LPRng unconditionally.

From the spec file:
# Obsoletes LPRng unconditionally.
Obsoletes: lpd lpr LPRng
Provides: lpd lpr LPRng = 3.8.15-3

This is a terribly broken behavior, for several reasons:

1) CUPS does not nearly provide the functionality available in LPRng
(for example, you cannot print to lpd queues which use GSSAPI/krb5
auth).  If RedHat no longer desires to support or package LPRng,
that's fine, but preventing anyone from using it seems like a poor
business decision.  LPRng can happily coexist with CUPS (that's kind
of the whole point of /etc/alternatives).  Is there a good reason why
CUPS refuses to play nice?  I am completely baffled as to why RedHat
has taken this "our way or the highway" approach to printing.

2) If someone chooses to package LPRng and install it on their RedHat
Enterprise system, and use /etc/alternatives to switch the printing
systems, it will happily work.  However, because of the unconditional
Obsoletes line in the spec file, up2date becomes convinced that cups
is out of date, and attempts to replace it.  However, cups is install
installed.  So update attempts to replace cups-1.1.17-13.3.6 with
cups-1.1.17-13.3.6 and discovers (of course) that it's already
installed, and bails.  

I do understand the need to obsolete older versions of LPRng that
RedHat packaged, but surely the line could be changed to obsolete
everything below 3.8.15.   This unfortunate problem with up2date and
cups has put a serious hitch in MIT's plans to distribute kerberized
lpr printing functionality to our user community.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install cups.
2. Create a package of LPRng that is specifically designed to play
nice with CUPS and /etc/alternatives and not clobber anything.
3. Install said package.
4. Run up2date and watch it want to replace CUPS with the same version
as is already installed.
5) Watch up2date fail, because it can't do that.

Actual Results:  "Package cups-1.1.17-13.3.6 conflicts with installed
package cups-1.1.17-13.3.6"

Expected Results:  CUPS and LPRng should be able to coexist, just like
they did for years in previous RedHat versions.

Additional info:

Comment 1 Tim Waugh 2004-07-16 14:31:59 UTC
Yes, this obsolete tag should be versioned as you suggest.

Comment 2 Jonathan Reed 2004-09-07 19:28:07 UTC
So, can we expect to see this in an update soon, or will this have to wait for RHEL 4?

Comment 3 Tim Waugh 2004-09-09 17:26:33 UTC
The fix will appear in any future CUPS update for RHEL 3, as well as

Comment 4 wdc 2004-09-09 20:47:21 UTC
It is disappointing that this fix was not deemed worthy on its own
to drive an updated CUPS package for RHEL 3 update 3.

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