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
Attachment:
pgpVTdA4DL4Te.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
