Spilt libperl from perl

[David Woodhouse]

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