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

[Klaus Singvogel]

Michael Sweet wrote:
> Klaus Singvogel wrote:
> >Michael Sweet wrote:
> >[...]
> >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...)

Sorry, but I read different:

   http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
   [...] AMD64 must place 64-bit libraries in /lib64, and 32-bit
   libraries in /lib.


> 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.

Debian is a large community... That's IMO the reason that they are
not able to participate at the LSB / FHS.

And additional: Debian has different paths for non-glibc linked
libraries (but maybe I mixed here something).

Sorry, but it's Debian who ignores the standards. I cannot convince
them to support those Standards, which were made for 3rd party.

> 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.

Yes, that's why we want 64-bit AMD64 binaries, why we want IA64
binaries, why we want S390 binaries, why we want PPC, PPC64, ...
binaries.

Alternatively they should just release their software as OpenSource,
and we will do this support (and vendors: please, release all parts as
OpenSource, even the libraries).

But I fear printer vendors will never understand that we have Linux
for different platforms. And if you give them a temporary solution to
use 32-bit binaries on the AMD64, it will be used for ever.

> >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.

Then someone needs to rebuild them.
....if they are not OpenSource, the vendor must do so.

> >- 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.

HP isn't a small company, and they have a large spectrum of printers.
HP can provide source code, why not others?

It's an old, outdated thinking, that vendors cannot provide source
code. If you accept this, then you want a customer of printer to
swallow a bitter pill. There are many reasons, why the customers
should insist on getting OpenSource drivers: e.g. as soon as the
interface (libraries) change, the driver might no longer be usable, if
a company is bankrupt, the code is no longer accessible, I told
already others reasons, and there are even more.

> 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...

I don't agree, because it's against the standard (see above).

We want to support more than one (two) architectures. If ISV or
printer vendors cannot handle this fact, then you might be true, then
they might get pushed away from us.

BTW: I'm sorry, but what does HSVs mean? I didn't find a fitting
explanation in wikipedia: http://en.wikipedia.org/wiki/HSV


> >  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.

Again: It is not FHS compliant.

Regards,
	Klaus.
PS: Enjoy your weekend, I will do now. :-)
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel at SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27