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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
