Re: RFC: Idea for improved diversions and alternatives handling
- To: email@example.com
- Cc: firstname.lastname@example.org
- Subject: Re: RFC: Idea for improved diversions and alternatives handling
- From: Goswin von Brederlow <email@example.com>
- Date: Tue, 01 Jul 2008 18:44:45 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20080628223705.GC6536@jamessan.com> (James Vega's message of "Sat, 28 Jun 2008 18:37:05 -0400")
- References: <email@example.com> <20080622192439.GC11581@dario.dodds.net> <firstname.lastname@example.org> <20080623074359.GC12971@dario.dodds.net> <email@example.com> <firstname.lastname@example.org> <20080628090305.GE29986@dario.dodds.net> <20080628223705.GC6536@jamessan.com>
James Vega <email@example.com> 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?
> I don't think this scenario makes sense outside of transitioning a
> diversion from one package to another.
> There are two use cases to consider regarding multiple packages and
> 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).
It is not allowed for two packages to contain the same file without a
diversion. I see no reason to suddnely allow it if a 3rd pckage
diverts the file. dpkg should just complain that the file already
> 2) Multiple packages diverting the same file.
> This currently isn't possible since dpkg-divert will rightly complain
> about multiple packages trying to divert the same file. If it were to
> be possible, you would need a layered approach with priorities so
> there's a defined notion of which package is currently providing the
> contested file and who would do so when that package is removed. In
> this case, congratulations, you've reinvented alternatives.
I think this should really be limited to transitioning a diversion
from A to B. As such dpkg should recognise that A looses the diversion
and B gains it and only change the owner of the diversion in its
database. Nothing else changes. This would require that both A and B
are updated as pair but that is nothing new.