Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 136973

Summary: cancel-cups man page missing from errata package
Product: Red Hat Enterprise Linux 3 Reporter: Andrew Schultz <ajschult784>
Component: redhat-rpm-configAssignee: Elliot Lee <sopwith>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: aleksey, alessandro.crespi, anton.rops, jcaruso, joshkel, me, nhruby, paolo, ralston, ronald, tao, traverj, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: https://rhn.redhat.com/network/software/packages/file_list.pxt?lower=351&upper=400&pid=279886
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-12 18:47:17 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:

Description Andrew Schultz 2004-10-24 16:26:22 UTC
The cancel-cups man page (/usr/share/man/man1/cancel-cups.1.gz)  is
missing from security errata package (cups-1.1.17-13.3.16), but the
link (cancel.1.gz) is still created.

Comment 1 Tim Waugh 2004-10-27 13:39:27 UTC
This is put into %{buildroot} and listed in the manifest
(%{_mandir}/man?/*) so there's nothing I can do to fix this in the
spec file.

For some reason rpm is ignoring this symlink.  Note that it is a
symlink to a target that does not exist at package build time (but
does after package install).

Comment 2 Andrew Schultz 2004-10-27 14:29:36 UTC
rebuilding from the .spec worked (included cancel-cups.1.gz) with rpm
v4.2.3-10.

But cancel-cups.1.gz is a symlink to lp.1.gz.  Shouldn't it be a
symlink to lp-cups.1.gz?

Comment 3 Tim Waugh 2004-10-27 14:35:57 UTC
lp.1.gz should be (and was) fine.  It is provided by the alternatives
program post-install.

If this is a change in build configuration it might have more
widespread consequences, so we need to know what the change was and
why it was made.

Comment 4 Andrew Schultz 2004-10-27 15:13:30 UTC
> lp.1.gz should be (and was) fine.  It is provided by the alternatives
> program post-install.

certainly.  But logically, shouldn't it point to lp-cups.1.gz?

Comment 5 Tim Waugh 2004-10-27 15:27:18 UTC
Yes, it probably should.

Comment 6 Tim Waugh 2004-11-08 16:42:29 UTC
Duplicate: bug #138284.

Comment 7 Tim Waugh 2004-11-15 11:25:47 UTC
*** Bug 138284 has been marked as a duplicate of this bug. ***

Comment 8 Tim Waugh 2004-11-15 11:26:12 UTC
*** Bug 139333 has been marked as a duplicate of this bug. ***

Comment 10 John Caruso 2004-11-16 00:21:32 UTC
I was about to file a bug on this same issue, but then I happened to 
do the right search to find this one.  So: what is the status?  Based 
on comment 1 it looks like there may be no plan to fix this?  It 
doesn't seem like it should be difficult to address (and it wasn't a 
problem in the previous cups RPM).


Comment 11 Tim Waugh 2004-11-16 09:08:25 UTC
Actually comment #4 has a probable workaround.  I'm waiting for an
analysis of the build system change before proceeding.

Comment 12 Tim Waugh 2004-11-26 10:58:16 UTC
*** Bug 140898 has been marked as a duplicate of this bug. ***

Comment 13 Matthew Saltzman 2004-11-28 16:07:12 UTC
This all works fine in FC3, where the chain of links is 

$man/cancel.1.gz -> $alt/print-cancelman -> $man/cancel-cups.1.gz ->
$man/lp.1.gz -> $alt/print-lpman -> $man/lp-cups.1.gz 

where $man is /usr/share/man/man1 and $alt is /etc/alternatives.

In RHEL, the link $man/cancel-cups.1.gz is missing, but the rest of
the chain is intact.

This isn't to say that the links are done in the most appropriate way,
just that they are all there in FC3, so comparing that spec file and
this one should give a clue.

Comment 14 Tim Waugh 2004-11-28 19:41:22 UTC
No -- the change was in the build system, not the spec file.

Comment 17 Josh Bressers 2005-01-12 18:47:17 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-013.html