[cups.bugs] Re: [MOD] STR #1524: SERVERBIN hard-coded to/usr/lib/cups (should be /usr/lib64/cups on 64-bit Linux)

Michael Sweet mike at easysw.com
Fri Mar 31 04:32:19 PST 2006


Klaus Singvogel wrote:
> Michael Sweet wrote:
> [...]
>> If you *do* decide to install in /usr/lib64, then you MUST add a symlink
>> from /usr/lib64/cups to /usr/lib/cups, otherwise you will break every
>> third-party CUPS add-on.
> 
> SUSE will only install into /usr/lib64, and will NOT install the
> symlink from /usr/lib64/cups to /usr/lib/cups. Otherwise I fear, we
> break the FHS standard (64bit binaries are accessable under /usr/lib).

This is one of the reasons we find that SuSE is no longer usable for
commercial development/support.  You need to be more ISV friendly if
you want to promote larger acceptance of Linux!

The FHS does not specify any of this.  The *LSB* does not prevent
64-bit object files from being in subdirectories in /usr/lib, only
64-bit object files *in* /usr/lib, and only for the x86_64
architecture (there are different rules for different archs...)

You'll also note that Debian doesn't follow the LSB on x86_64
and puts 64-bit stuff in /usr/lib and 32-bit stuff in /usr/lib32.

The problem with mixed-mode architectures is that you can never
know whether a developer will provide 32-bit or 64-bit binaries.
If you only install in /usr/lib64/cups, then 32-bit binaries will
not work out-of-the-box - they will not be seen by CUPS, and you
risk having a well-meaning user reconfigure to use /usr/lib/cups
and break all printing.

> The solution is for me so far:
> - Third party users could use "cups-config --serverbin" for correct
>   installation.

Ideally, yes, but that does not work for existing packages (binary
or not) that install in /usr/lib/cups.

> - If 3rd party provide 32bit binaries only :( and if they don't have
>   OpenSource packages, :( they really don't take care about their
>   customers. But it's not on the Linux distribution to support any
>   such rude behaviour and break standards.

You only want to support companies that provide source code, but
most printer vendors cannot provide source code due to licensing
and trade secret issues.  The issue is analogous to 3D/OpenGL
driver support in the X server.

It isn't rude, and it isn't breaking standards.  *You* will be
the one breaking the standards and being rude and pushing ISVs
and HSVs away from SuSE...

>   Instead it should be clear communicated to the customer that the
>   3rd party is breaking the standards and he should bring back his
>   device.

Nope, CUPS and FHS define the standard in this case - /usr/lib/cups is
the filter directory on Linux, period.  It is the only FHS-
compliant directory we have available.

> - We should discuss, why cupsd doesn't support additional paths, where
>   sever binaries could be located.

There is an open RFE for this that will be part of CUPS 1.3.

Suffice it to say that it isn't as simple as adding a FilterPath
directive, or to come up with a Linux-only solution.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com




More information about the cups mailing list