Bug 128024 - cups obsoletes LPRng unconditionally
cups obsoletes LPRng unconditionally
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-16 10:12 EDT by Jonathan Reed
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.1.17-13.3.16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-15 06:38:25 EST
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 Jonathan Reed 2004-07-16 10:12:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Gecko/20040301

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):
cups-1.1.17-13.3.6

How reproducible:
Always

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 10:31:59 EDT
Yes, this obsolete tag should be versioned as you suggest.
Comment 2 Jonathan Reed 2004-09-07 15:28:07 EDT
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 13:26:33 EDT
The fix will appear in any future CUPS update for RHEL 3, as well as
RHEL 4.
Comment 4 wdc 2004-09-09 16:47:21 EDT
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.