Re: Declarative Diversions - GSoC Project Update 1

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

Steve Langasek <vorlon@debian.org> writes:

> On Tue, May 31, 2011 at 09:49:26AM +0200, Goswin von Brederlow wrote:
>> Raphael Hertzog <hertzog@debian.org> writes:
>
>> > On Mon, 30 May 2011, Goswin von Brederlow wrote:
>> >> Sam Dunne <sam.dunne101@gmail.com> writes:
>
>> >> > This project will infer --add, --remove and --package and will not
>> >> > allow you to specify them.
>
>> >> > The same is goes for --rename, it is being made default and not optional (for
>> >> > now, I am aware of some special cases).
>
>> >> > --divert will not be specifiable and will take the default format
>> >> > "file.divert-$package".
>
>> >> What about moving a diversion from package A to B?
>
>> > That's why we have "Conflicts" to ensure a package is removed before the
>> > other is installed.
>
>> But we only need breaks+replaces there.
>
> In theory.  Do you have an idea for a non-brittle mechanism that would let
> this work for diversions in practice?

That would be for him to figure out an implement.

We have the following case:

old A: has diversion
old B: does not have diversion

new A: does not have diversion
new B: does have diversion
new B: Replaces: A (<< new), Breaks: A (<< new)

A and B can be unpacked in any order as long as A gets deconfigured
first. The problematic case is B getting unpacked first.

I would make dpkg be able to track multiple diversions but only one
of the diverting packages may be configured at any one time. Dpkg would
have to track which packages diversion was last active (what the current
diverted name of the file is) and update that when configuring a
package.

I never liked the breaks+replaces because it breaks downgrades (or
even just reverting all failed upgrade) by loosing files. So maybe
moving a file from A to B should go back to using Conflicts? At least
for the case of diversion.

MfG
        Goswin