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