This also appears to affect RHEL4 as well.
+++ This bug was initially created as a clone of Bug #434967 +++
This affects Red Hat Enterprise Linux 5 as well.
+++ This bug was initially created as a clone of Bug #249768 +++
Description of problem:
cups uses the "alternatives" technology and so it calls the following script
/usr/sbin/alternatives --install /usr/bin/lpr print /usr/bin/lpr.cups 40 \
--slave /usr/bin/lp print-lp /usr/bin/lp.cups \
--slave /usr/bin/lpq print-lpq /usr/bin/lpq.cups \
--slave /usr/bin/lprm print-lprm /usr/bin/lprm.cups \
--slave /usr/bin/lpstat print-lpstat /usr/bin/lpstat.cups \
--slave /usr/bin/cancel print-cancel /usr/bin/cancel.cups \
--slave /usr/sbin/lpc print-lpc /usr/sbin/lpc.cups \
--slave /usr/share/man/man1/cancel.1.gz print-cancelman
In this case, "/usr/share/man/man1/cancel-cups.1.gz" is the "real" physical file
and /usr/share/man/man1/cancel.1.gz should (via
/etc/alternatives/print-cancelman) to the real one.
Unfortunately the cancel-manual is not named "cancel-cups.1.gz" but only
"cancel.1.gz" instead. So the link /etc/alternatives/print-cancelman points is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install cups
The problem can be fixed by applying the following patch to cups.spec:
--- cups.spec.old 2007-07-13 11:49:07.000000000 +0200
+++ cups.spec 2007-07-26 23:19:01.000000000 +0200
@@ -202,7 +202,7 @@
mv lpc lpc.cups
-for i in lp lpq lpr lprm lpstat; do
+for i in cancel lp lpq lpr lprm lpstat; do
mv $i.1 $i-cups.1
The patch basically adds the "cancel" manual to the list of manual files which
should be moved to *-cups so that they can be used with the mentioned
There is only one small problem: after updating, the links are still broken
until the next call of "alternatives --config print"
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Turns out this doesn't affect RHEL-4.8 after all.