Spilt libperl from perl

Hans de Goede j.w.r.degoede at hhs.nl
Mon Apr 23 20:21:03 UTC 2007


Bill Nottingham wrote:
> Warren Togami (wtogami at redhat.com) said: 
>>> This solves the problem for now, and we already are planning to change
>>> multilib for F8.
>> Any written plans of how exactly multilib will change for F8?
> 
> 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.
>   
>   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
> 
> 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).
> 

Actually 2 is a problem that multilib doesn't solve, I've written some scripts 
/ hacks to be able to build i386 on x86_64 without using mock because I have a 
slow link and thus mock used to take eons, now it only takes ages (--autocache 
rules!). However these scripts were a big hack, and even with this big hack 
things didn't always work properly. Using mock is the only sane way to build 
i386 packages on an x86_64 install.

> 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.
> 

Yes 1 is a very important reason to have multilib support, actually the only 
reason if you ask me, because as said 2 is seriously broken.

So I think any new multilib strategy should solely target 1.

Regards,

Hans




More information about the Fedora-maintainers mailing list