Re: Multiarch and idea for improved diversions and alternatives handling
Neil Williams <codehelp@debian.org> writes:
> On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote:
>> James Vega <jamessan@debian.org> writes:
>>
>> > On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
>> >> So if we allow multiple packages to be installed at the same time which
>> >> divert the same file, then I think we have another case for wanting to
>> >> continue supporting an optional diversion target - or at least for not using
>> >> ".diverted" by default, since we wouldn't want diversions from multiple
>> >> packages to collide. Maybe ".diverted-$package", then?
>
> (My internet connection has been very flaky since this thread started
> and I have only been able to post intermittently so apologies if this
> appears to be late or "out-of-sync" with other posts.)
>
> Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
> when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
> package under that, as we do with dpkg-cross currently:
>
> /usr/lib/
> /usr/arm-linux-gnu/lib/
>
> /usr/include/
> /usr/arm-linux-gnu/include/
>
> multiarch could even add:
> /usr/share/
> /usr/arm-linux-gnu/share
Because it pollutes top level directories, namely / and /usr. Think
how it will look with 12 abis coexisting. People felt that putting the
dirs below /lib/, /usr/lib/ and /usr/include/ would be less invasive.
But algorithmically it is all the same. None of the problems change in
any way by using one or the other.
> This adds only one new directory, it keeps the main contents of the
> package in a single location (making it easier to manage and parse
> things like dpkg -L) and it means less changes for existing packages
> that use these paths already.
>
> It also means no need for extra diversions at all, no need for Replaces:
> and no headaches when removing the multiarch vs removing the primary
> package etc.
I think you are mixing things up here. The problem where diversions or
replaces where thought about in multiarch is for
/usr/share/doc/package/copyright and changelog. Policy dictates they
exist and where they have to exist and that becomes a problem.
On the other hand the RFC for diversion and alternative handling had
nothing to do with multiarch at all and is a totaly seperate line of
thought.
> BTW I think it is a mistake to want to use /usr/lib/i386/ when it is
> entirely possible that multiarch users will actually need the full
> triplet - think about hurd or kfreebsd as multiarch packages.
Nobody wants to use /usr/lib/i386/. It was always the triplet.
>> > There are two use cases to consider regarding multiple packages and
>> > diversions.
>> >
>> > 1) Multiple packages installing a file that has been diverted.
>> > Currently, there is only one "divert to" filename so you'll end up
>> > losing data once the second diverted file is installed. This could be
>> > alleviated by instead basing the "divert to" filename on the package
>> > which contains the file being diverted (as you suggest above).
>> >
>> > There's still the problem of what to do when the package providing the
>> > diversion is uninstalled as now you have conflicting packages.
>> > Actually, you already had conflicting packages that just weren't
>> > affected yet because of the diversion, which leads to 2).
>
> If the multiarch package can be installed alongside the primary without
> any conflicts by using /usr/$triplet instead, then the need for the
> diversion and consequent hacks goes away entirely.
Again nothing to do with multiarch. This is about unrelated packages
having conflicting files and one diverting the other(s).
MfG
Goswin
Reply to: