[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)
David Woodhouse
dwmw2 at infradead.org
Thu Apr 26 21:39:23 UTC 2007
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
More information about the Fedora-maintainers
mailing list