Spilt libperl from perl

[Hans de Goede]

David Woodhouse wrote:
> 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.
> 


What can I say, all this sounds like I could have written this myself, so this 
gets a huge +1 from me. BTW, I think bug 235755 is a dup of a bug of mine 
(filed against rpm).

Regards,

Hans