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

[Klaus Singvogel]

Michael Sweet wrote:
> Klaus Singvogel wrote:
[...]
> >So, I think it's the right step not to include the 32-bit libraries
> >in a 64-bit package.
> 
> It makes package management almost impossible.  In particular, the
> way SuSE packages the 32bit CUPS libraries, you can't install an
> alternate version of those packages without wiping that package,
> which then triggers other dependencies.  It ain't pretty.

Sorry, but I think, I'm currently unable to catch your here.

In my point of view, it's impossible to replace files by a new,
alternate version, without removing (you say "wiping") the old
files, if the file names are the same. And a replacement is always
done by "rpm --update" or "rpm --freshen". 

If you have different (= not overwriting) file names in your alternate
package, you can install them parallel in your system. Just say "rpm
--install". :-)

But this is trivial, so I got the feeling, I misunderstood you here.

Maybe it's the "triggers other dependencies", which contains a lot of
room of speculation.

> I've had the displeasure of providing support for your customers
> who have no end of trouble with your CUPS packages...

I wasn't aware of this. Sorry.

May I ask you, what the trouble was in particular?

> Given that I am *not* disconnected from customer support like you
> are, I see a lot more problems than you do, apparently.

Yes, it sometimes is an advantage, if you don't have to do customer
support, especially, if you more packages and not just the printing
system at all.

But on the other side, I'm sitting in middle of two chairs with
different opinions: the security team, which wants a lot of
restrictions regarding open daemons, and the customer who sometimes
wants a lot of freedom of his system. Both opinions contradict...

As a side note: as I already read in one of your announcements that
cups-1.2 will no longer run as user, it might be possible I'm unable
to avoid that the start of the daemon is disabled in a standard
system. The user might need to push a button to enable it in future.
This will happen then through demands of our security team.

> No, I would need twice as many build systems to accomplish the
> same thing that I do now.  I would need to make sure they had
> compatible versions of every library, use the same version of
> GCC, etc.  Then I would need to merge *some* of the packages
> from the 32-bit build systems into the final distribution
> image for the 64-bit systems.

We use a mechanism, called "autobuild", which lets you install any
version of any released SUSE distribution at your local system. It
sets up and uses a chroot environment for doing so (its included in
our distributions). This helps.

On the other side, you still need a host of every architecture to
build any such distribution, and you cannot test any hardware
connections (like USB) in such a chroot'ed build environment.

Nevertheless, it reduces the number of build hosts at SUSE.

> Now, if I want to provide the 32-bit libraries in a separate
> package, all I need to do it make a separate "cups-libs32"
> subpackage, however that would break 32-bit packages that have
> a dependency on cups-libs, and if I used the same name as the
> 64-bit package, that would only be confusing to the user.

SUSE ships "cups-libs-1.1.23-21.x86_64.rpm" and
"cups-libs-32bit-1.1.23-21.x86_64.rpm" (please note the "-32bit") on
the 64bit installation media. Which is excatly doing, what you talk
about: providing the 32-bit libraries and 64-libraries for the
customer.

The dependency is solved through the 64-bit package.

[...]
> RPM is available on Solaris and IRIX, but not the default.  In any
> case, it *is* relevant to the discussion of multiple-architecture
> platforms because they've been doing since long before SuSE was
> around!

Sorry, to disagree again, but we talked about use of rpm macros for
multiple-architecture platforms.

But I cannot disagree that Solaris and Irix are multiple-architecture
platforms. L) I know Solaris a little bit from live before SUSE and
know that the pkg-programs are used for installation as default
choice. :)

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