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

[David Woodhouse]

On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote:
> multilib design (TM) is the (un)art of splitting only the libdir for
> archs and performing ugly hacks to cross-overwriting techniques.

It's the art of splitting the libdir. The ugly hacks were an
implementation detail which are largely unnecessary when you stop and
actually think about it.

> As such the punchhole remove/install problem is an embedded issue of
> the multilib design (TM).

Not at all. It's just an aspect of the dirty hack we put in RPM to allow
conflicting binaries to be installed. Not a fundamental problem with
multilib at all.

> The "David Woodhouse improved multilib design that requires bin
> suppackage splits for every bin carrying package" tries to circumvent
> this problem by spliting out the bin contents in subpackages. But this
> is another bad short-term decision, as it
> 
> o forces us to revisit every bin carrying package out there speding
>   tons of resources better used elsewhere

You overestimate the effort involved. It can be checked automatically,
and when conflicts are found, the fix is simple.

> o still does not allow us to simply have two disting repos for both
>   arch, since we would have to filter out all bin subpackages

No, because you _want_ both sets of bin subpackages available. The user
gets to install the secondary version _if_ they want it.

> o If we don't filter then we just pass the problem to all depsolvers,
>   e.g. yum, smart, apt

No, those just install the primary architecture. The secondary arch only
ever gets installed if the user specifically asks for it.

> In comparison the bin64 solution costs us almost nothing:
> o most packages will rebuild in unattended mode
> o breakage of false bindir will be detected during the build itself
> o You can use two cleanly distinct repos with the depsolver tools of
>   today, no need to add any funny support anywhere
> o You fix an FHS violation, in exchange for another, which just brings
>   us bad to balance
> o The FHS has already considered this (thanks to the Debain folks) and
>   is waiting for distros to actually utter the demand to include it.

It buys you the ability to install _both_ versions of the package
simultaneously, but you can't easily choose which version to prefer for
a _specific_ package -- you can only set bin64 before or after bin in
$PATH, which affects _all_ installed programs. Unless you split the
packages out so that you can have libraries installed for the secondary
arch without having to have the binaries, I suppose? :)

-- 
dwmw2