[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch and idea for improved diversions and alternatives handling

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:



multiarch could even add:

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.

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.

> > 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.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: