ppc64 builds

[Jesse Keating]

On Sunday 18 March 2007 14:50:06 David Woodhouse wrote:
> Ideally, I think we want a new RPM tag for it, and it can be specified
> in the specfile. The package author can then specify whether the package
> should be shipped for the secondary arch (i386 on x86_64, or ppc64 on
> ppc64), and even whether the secondary version should be _favoured_
> (64-bit gdb on ppc64).

Unfortunately multilib isn't well understood by a large majority of our 
maintainers, both inside RH and without.  Leaving it up to the maintainer is 
pretty much going to result in the vast majority of packages not being 
multilib, especially the first time a multilib problem is found, boom, 
multilib off rather than fixing the problem.

Add to that the confusion of "Hey, I set my package to not be multilib, why is 
it landing in the tree as multilib" when we bring things in due to deps of 
some other package that was marked as multilib.

These are just a couple of problems I see with leaving it up to the 
maintainer.  Not that there aren't problems with the way it is done now, but 
at least there we can typically blacklist something (if it isn't brought in 
by deps) or re-adjust the packaging to make it more sane.  Firefox was a 
rather unique situation and an unfortunate outcome, but I don't think it is 
fair to base the entire multilib experience on Firefox ppc64, something which 
extremely few of our users would have seen/experienced.

But I do appreciate you thinking about how to better manage this!

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070319/33ca63c8/attachment.sig>