Bug 193987 - Cups upgrade for x86_64 is broken
Cups upgrade for x86_64 is broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
5
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
: Reopened
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-06-03 19:10 EDT by Nicola
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.2.1-1.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-20 05:54:10 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 Nicola 2006-06-03 19:10:45 EDT
Description of problem:
Latest upgrade for cups x86_64 is broken

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


How reproducible:
Always

Steps to Reproduce:
1. upgrade FC5 x86_64 to cups-1.2.1-1.2

2. /usr/lib64/cups/ is upgraded to /usr/lib/cups/
3. Executables seem to be x86_64 but they are located in the wrong place.
  
Actual results:
Some custom modifications, like drivers for Canon printers with provided source
won't work anymore as cups now is located in the wrong place.

Expected results:
Printing should work as usual. Previous version did.

Additional info:
Comment 1 Tim Waugh 2006-06-04 07:30:04 EDT
No, this is the correct place.  They are executables, not libraries, and so do
not need to be in lib64.

In point of fact, I asked the upstream maintainer, Michael Sweet from cups.org,
about this issue, and whether /usr/libexec would be a better place -- his
response was that it would, if the various standards actually agreed on whether
it should exist.  Mike requested that our packages use the same locations as the
unpatched cups software: /usr/lib/cups/*.
Comment 2 Nicola 2006-06-04 09:24:41 EDT
All the executables were in the same /usr/lib64/cups place, including
the former cups-1.1.23-30.2.x86_64.
Now with the latest version someone decided to put cups instead in /usr/lib/cups
thus breaking some functionality, as I've written.
In /usr/lib/cups/filter there are several filters compiled for x86_64, its
location is illogical at least.

Breaking functionality is always a bad thing. The "corrected" package should
always issue a warning after such a drastic change, and should copy the existing
filters to the new location. 
What will happen to non experienced users when they discover their printer won't
work anymore?
Comment 3 Tim Waugh 2006-06-08 06:56:16 EDT
Please try this test update:

  https://www.redhat.com/archives/fedora-test-list/2006-June/msg00081.html

You should be able to fetch it using this command, as root:

  yum --enablerepo=updates-testing update 'cups*'
Comment 4 Paul Wayper 2006-06-14 02:21:19 EDT
There are two other problems with this change:

Firstly, cups still (AFAICT) looks in /usr/lib64/cups/backend for the drivers,
despite them being in /usr/lib/cups/backend.  I can symlink the latter into the
former and get printing working, but this is still broken as designed.

Secondly, shouldn't 'executables' be in something like '/usr/share/cups/backend'
rather than '/usr/lib' at all?  Isn't this patch just a very hasty, badly-made
decision overall?
Comment 5 Tim Waugh 2006-06-14 04:48:28 EDT
1. No, it only looks in /usr/lib64/cups/backend if the sought backend is not
present in the correct directory, /usr/lib/cups/backend.  At least, that's the
idea -- are you seeing different behaviour than I am?

2. Executables should certainly not be in /usr/share, which might be shared
across different architectures!  No, /usr/lib is perfectly fine for executables
(libraries would be a different matter!).  My first choice would be /usr/libexec
(which is probably what you mean rather than /usr/share?), but in the interests
of compatibility with other distributions -- and the availability of future 3rd
party drivers to all distributions -- we will follow the upstream decision here.
Comment 6 Paul Wayper 2006-06-14 22:14:39 EDT
1) It was in 1.2.1-1.2, but in 1.2.1-1.7 (which I upgraded to today) it's fixed
AFAICS.

2) OK, /usr/bin/cups/backend then.  I'm no distro lawyer, but /usr/lib is for
libraries IMNSHO :-)

3) I need to submit a bug on bugzilla to stop it wrapping lines so stupidly!
Comment 7 Tim Waugh 2006-06-20 05:54:10 EDT
Regarding (2): really, /usr/lib is the best place to fit within the upstream
constraints.  The point really is to make sure we are compatible with other
distributions for 3rd party drivers, and we do that by following the upstream
behaviour.  By all means talk to the upstream CUPS developers to get them to use
/usr/libexec instead; as I mentioned earlier, I already tried this myself.

Thanks for testing.

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