[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Phil Knirsch]

Axel Thimm wrote:
> On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>> On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote:
>>> On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>>>> You're trying to solve a different problem.
>>> The main issue is that while FC1.92 started by allowing selected libs
>>> form i386 to coexist to assist in installing i386 packages for not yet
>>> available x86_64 counterparts, it has evolved to more and more libs,
>>> even for stuff that none will really be interested to install the i386
>>> part of, and even for developing i386 on x86_64.
>>>
>>> So the problem domain slovly changes and multilib is not adequate to
>>> serve the needs. We either need to admit that and reduce the specs to
>>> what multilib can do on paper and also fix the issues in
>>> implementation, or find a better solution that serves the changed
>>> demand.
>>>
>>> That's what this is all about, and given the bad history of multilib
>>> support in rpm, a solution that does not involve any fiddling with
>>> rpm, yum, anaconda, smart, apt, ... is preferred.
>> rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be
>> installed.
> 
> Actually rpm did that before multilib was added, so in fact your
> request to "fix" rpm means to remove multilib support. With which I
> agree 100%, because that only inflicted pain.
> 
>> Current multilib allows you to run 32bit apps, for example
>> googe-earth as well as develop/debug other 32bit software. That's
>> good enough for me and I suspect for many people as well. Now if
>> only yum wouldn't try to install both package.i386 and
>> package.x86_64 when I try yum install package and if there were no
>> problems with shared files between 32/64bit packages, all would be
>> well.
> 
> Well, while some bugs could be fixed like the nuking of %doc and %lang
> (although it is agrued that the multilib design in rpm is so awkward
> that this requires major rewrite work in rpm which is why it isn't
> beeing done), others like the punchhole bug cannot w/o removing the
> multilib support in rpm. Which is why I summarized this as "multilib
> needs to die, multiarch rulez".
> 

One thing you have to be very careful about multiarch is that you don't 
fall for the easy solution.

Just adding [loadsofprefixes]/bin64 will not fix world hunger, 
especially when you then suddenly in the years to come get a CPU that 
might support 32bit and 2 64bit archs. Then you're then screwed all over 
again, just like with the "No application will ever need more than 640kb."

The solution debian and Gentoo iirc use which are basically buildroots 
is the only way i know how you can cleanly separate various archs on one 
system. Sadly you'll then loose the common and sharable files, but any 
other solution will need very carefull and detailed planing.

(You could ofc ahackishly lways just run hardlink on / after each 
package installation ;) ).

Read ya, Phil

-- 
Philipp Knirsch      | Tel.:  +49-711-96437-470
Development          | Fax.:  +49-711-96437-111
Red Hat GmbH         | Email: Phil Knirsch <phil at redhat.de>
Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
D-70178 Stuttgart
Motd:  You're only jealous cos the little penguins are talking to me.