Spilt libperl from perl

[Patrice Dumas]

On Tue, Apr 24, 2007 at 11:26:46AM +0100, David Woodhouse wrote:
> 
> Secondly, we should kill the dirty hack in RPM which allows packages
> with file conflicts in /usr/bin to be installed, with RPM silently
> choosing one of the available files. The decision about what to install
> should come from whatever's calling RPM; RPM shouldn't be
> second-guessing. We should fix our packaging so that these file
> conflicts don't exist -- packages with libraries which make sense on the
> secondary arch should not also have executables in the same subpackage.
> Bug #235757 covers this, as does the subject line of this thread. 

This should certainly also be considered by FESCo and the packaging 
commitee: if it enters the guidelines it should be fairly easy to push
packagers to fix their packages -- even before binaries conflict.

> > 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64
> > 
> > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere.
> > 
> > #2 has historically been a problem that multlib solved. In a fully open
> > Fedora world, it can be solved with mock (assuming we throw up a full
> > ppc64 tree somewhere).
> 
> Multilib hasn't actually solved it very reliably, in a world where so
> many people make the mistake of using autoconf. I believe that
> pkg-config, in particular, will also always get it wrong. (Bug #224037)

I don't think autoconf itself is a show stopper. And anyway these are
bugs outside of fedora (ie upstream). Allowing people to develop i386
apps on a x86_64 box would help solving thoses issues. I don't think we
should force developpers to use chroots for building normal packages
on fedora, but instead leave them the choice, be it only to leave them
the opportunity to fix their packages to build right in multilib
environment and be able to spot bugs in the tools (like pkgconfig
issues).

--
Pat