On Sun, Apr 29, 2007 at 08:43:59PM +0200, Christian Iseli wrote: > On Sat, 28 Apr 2007 13:17:26 +0200, Axel Thimm wrote: > > There could also be > > > > 3) No one gets /bin, /lib directly, everything gets bult into > > bin32/bin64 etc. and bin and lib are set as follows (symlinks) > > > > i386: bin -> bin32, lib -> lib32 > > x86_64: bin -> bin64, lib -> lib64 > > ppc: bin -> bin32, lib -> lib32 > > ... > > > > That would give you proper symmetry, reusable packages from one > > arch onto another (e.g. not packaging extra i386 packages for > > x86_64), and bin/lib would always point to the native components. > > Another type of thing that worries me with this schema: > $ rpm -qf /bin/ls > file /bin/ls is not owned by any package > > In short: you are throwing a whole lot of typical assumptions > about a Unix/Linux system out the window... and my gut feeling is that > they'll come back haunting us in various unpleasant ways for a long > time. That's a problem in general that we need to be aware of. The moment any scheme starts not to prepare multilib/multiarch on the server side, but simply activate both repos on the client side you will have the issue that /bin/ls will be owned by two packages from different archs, and you need to hope that the depsolver will pick the right one. But this is a common issue with any scheme that will allow full unfiltered access to both repos. In the scheme 3) above one could automatically %ghost-own all (s)bin symlinks, which would solve the issue of /bin/ls existing in the rpm database, but not the general issue of parallel repo enablement. So, in a nutshell: There will be two classes of solutions, one that prepare the x86_64 repo with selected i386 packages, either white/blacklisted/heuristic based etc, or solutions that allow full access to the i386 repos. And the latter class of solution will have to deal with shared file dependencies. Both the bin64 and David's solution fall into the latter class. -- Axel.Thimm at ATrpms.net
Attachment:
pgpsESNR2Ubwz.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
