Spilt libperl from perl

[David Woodhouse]

On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote:
> Warren Togami (wtogami at redhat.com) said: 
> > Any written plans of how exactly multilib will change for F8?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=multilib
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib

> No concrete plans. One idea:
> 
> - Have all repos be single-arch. Those that want multilb subscribe to both
>   repos, and have their packages determined by a yum plugin.

Amen. It would be nice if we could have them subscribe to the _normal_
i386 repo -- rather than having a separate repo with just a subset of
packages. The whole crappy 'has a -devel subpackage' heuristic can just
die, but this works _ONLY_ if we fix the tools to do the right thing
when the full set of secondary-arch packages is available.

For a start, that means fixing yum to refrain from installing both
versions when asked for packages by name. It should install only the
primary arch unless explicitly asked to do otherwise. I think that's the
same as bug #235756 which is filed against the installer. Should it be
moved to yum?

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. 

We _might_ get away with just fixing RPM so that it generally does make
the right decision (in particular, installing 32-bit executables on
ppc64 and sparc64). But that's a crappy workaround typical of the kind
of half-arsed crap we've done for multilib in the past; RPM itself is
the wrong place to make such a decision. It lives at a higher level.
However, 'fixing' RPM might be the easiest option before F7, to fix the
perl breakage we've just introduced again -- but it's certainly not the
right answer in the long term.

>   Pros: simple for repo creation
>         allows users to customize what they want
>   
>   Cons: the plugin could take a not-insignificant amount of cpu time/ram to run
>         probably would need some core yum changes as well

I don't understand this plugin. What would it actually do?

If someone _wants_ something for the secondary arch, they'll install it
manually -- 'yum install firefox.i386', or 'yum install gdb.ppc64'.

> Basically, there are two reasons that extensive multlib support is/was
> needed:
> 
> 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)

Mock solves it for packages, and yum's 'installroot' option can do it
for random other builds if necessary.

> This leaves #1. You could certainly write algorithms to determine 'what
> is a runtime lib' that will operate on any package set and decide what
> to install. But, since any such algorithm will be iterating over the file
> set, it's unlikely to be fast.

Again I think I'm missing something. We already have algorithms which
handle dependencies on runtime libs. If I 'yum install gdb.ppc64' on a
clean system where I've already done 'yum remove glibc.ppc64' to get rid
of all that unwanted crap in the default install, it knows that it needs
to install ncurses.ppc64 and glibc.ppc64. What do we need that's new?

The only problem I'm aware of with dependencies is the _manual_ deps,
where a package 'foo-devel' might say that it requires 'bar-devel', but
in fact it should require 'bar-devel.%{ARCH}'. Because otherwise you get
stuff like pango-devel.i386 being satisfied by the existence of
cairo-devel.x86_64. Which doesn't actually work when you come to build
it. Bug #235755.

-- 
dwmw2