On Mon, 2007-04-23 at 14:39 -0500, Tom "spot" Callaway wrote: > I'm not going to support making a libperl subpackage to dodge fixing > multilib. By doing this, we just slide down the slippery slope of > avoiding the problem, and relying on dirty hacks instead of solving > the hard problems. I believe you retracted this on IRC, after I pointed out that this is actually the _fix_ to avoid the dirty hack in RPM which allows the installation of conflicting files. You said we'd go ahead and split the package. But it doesn't seem to have been done yet -- are we still going ahead with it? If not (and in fact even if we do), we need to at least fix said dirty hack in RPM so that it doesn't favour binaries of the secondary architecture. There's a patch which makes RPM honour a %_prefer_color macro at http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch With that fixed (and with anaconda setting %_prefer_color of course), and with the yum fix I just attached to bug 233427, I've just done a test install which looks a _whole_ lot better. I can 'yum remove glibc.ppc64 libgcc.ppc64' and it no longer wants to remove important stuff of the primary architecture, like initscripts.ppc :) Of course, it's still a bug (#235756) that we're installing all that crap for the secondary architecture by _default_ when almost nobody wants it. But at least with the minimal fixes we can get rid of it afterwards. Those minimal fixes don't affect non-ppc, and should be entirely safe for F7. -- 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
