On Wed, 2007-04-25 at 19:45 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > Another way of avoiding this issue, however, would be to have > > > normal conflicts in (/usr)/(s)bin. All the multilib enabled packages > > > would have to do subpackages without conflicting files and only those > > > subpackaged could be multilib parallel installable. This is another way > > > to solve the issue. You're talking about bug #235757, which is just one dependency of the multilib tracker bug: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > > Yes, but it does involve much more work to do. Packaging is hard. Let's go shopping. > It is something worth doing IMHO. Absolutely. > > And if we assume that > > every package is in principle candidate for multilib, we would end > > with a guidelines to have all packages using bindir to split off > > subpackages. The setting _bindir=/usr/bin64 would already fix the > > majority of packages w/o having to touhc the specfile. Yep. That seems to be the best, cleanest, fix. It helps a little bit if we fix RPM to actually make the _right_ decision when it's forced to choose between conflicting files (http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch), but really, RPM shouldn't be making those decisions. It should just be installing what it's told to, and it shouldn't be told to install stuff which conflicts. -- dwmw2 -- 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
