[cups.bugs] Re: [MOD] STR #1487: rpmbuild fails on x86_64

[Klaus Singvogel]

Michael Sweet wrote:
[...]
> You can do your packaging however you wish, however the purpose of
> the spec file we include is to a) package CUPS in the standard
> location on ALL Linux distributions and b) support generation and
> packaging of both the 32-bit and 64-bit libraries on the x86_64
> platform in a single RPM (i.e. no more hacks to produce a separate
> 32-bit library package like you currently use in SuSE...)

Yes. But you might have misunderstood the philosophy of SuSE then.
:-) We don't want to have a mixture of architecture files in a single
package file, if a package is named <<xxx>>.x86_64.rpm, then there is
x86 and 64-bit arch files in it. We distribute for every architecture
in an own file. It's up to the user (and part of the logic of our
package manager) to install only the minimum of needed architecture
files or not (i.e. I prefer having a clean 64-bit system and try to
refuse installation of 32-bit packages, but sometimes I cannot, like
for the realplayer).

As you already said: we prefer to have only a minimum set of files
from both architectures installed in one system, which means usually
the libraries and not the executables.
But isn't it our final goal to get rid of the 32-bit stuff for the
64-bit architecture? So we might want to install 32-bit libraries
only, if 32-bit binaries are present in your 64-bit system, and this
means for cups: the 32-bit libraries only if you have appropriate
library calls from any 32-bit executable. Otherwise you don't need to
bloat your 64bit system with 32-bit stuff, nor need to have a 32-bit
compile environment parallel installed.

So, I think it's the right step not to include the 32-bit libraries
in a 64-bit package.

BTW: SUSE is building the 32-bit CUPS libraries not in a multi-arch
system, instead 32-bit packages are build in a pure 32-bit system.
It's only a kind of "bonus" to have the 32-bit libraries included on a
64bit installation media. :-) We don't separate them via a "hack". We
produce them on a 32-bit system and include them for the 64-bit
installation, just for the any case. :-)

I never got informed about problems in the way we do. But I'm not
working for the support, so I'm not getting informed about any weird
ideas our customers might have had. :-)

But -- as said at the beginning -- it's a philosophy of SUSE, and
other vendors might have different valid reasons.

> The situation will only get more complicated if we try supporting
> Linux on 64-bit PowerPC, SPARC, or i-Series systems, as you may be
> compiling a 32-bit CUPS install with 64-bit libraries (that *is*
> supported on Solaris and IRIX already, BTW!)

We compile and successfully run the SUSE Linux Distribution on any of
the above mentioned architectures, and on some additional, exotic
archs too (but none is really public avail, as the costs for selling,
and support or make them just public avail are incredible higher than
the expected revenues).
You might be wrong with your assumption, that we don't support them. :-)

We never had any problems for supporting the architectures in the past
and in the way we do. Maybe this might influence the way how you do
the multi-architecture support so far? :-)


Another comment: I doubt that you can compile and link a 32-bit CUPS
libraries by using the 64-bit libraries only and without having access
to the appropriate 32-bit libraries in your build environment. So, if
you have both installed, why do you insist to include the files for
one architecture in the packages for a different one? Isn't it the
better philosophy to build and keep them separate and let the
decision be made finally by the user (and by the necessities of the
installed packages)?

Solaris and IRIX don't use RPM, don't they? It was one of my
preconditions to talk about rpm specific stuff only. I know that other
UN*X systems also support multi-architectures, but the discussed
macros and having a specfile is RPM specific. So, I don't see any need
to look on different OS's, when RPM specific stuff is discussed. :-)

But don't misunderstand me: I like it, that CUPS is not only a Linux
restricted printing system. I think there is a benefit in the
robustness of the code that CUPS runs on different OS too.

Regards,
	Klaus.
-- 
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