Re: RFC: Idea for improved diversions and alternatives handling

[Goswin von Brederlow <goswin-v-b@web.de>]

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

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

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

MfG
        Goswin