Re: RFC: Proposal to combine diversions and Replaces into DEBIAN/replaces
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Aug 13, 2010 at 11:18:32PM +0200, Goswin von Brederlow wrote:
>> The only real fix for this problem seems to be to preserve the replaced
>> files under another name and restore them when the replacing package is
>> removed. That starts to sound a lot like diversions doesn't it. The
>> only difference is that Replaces is usualy versioned.
>
> I think you are proposing a cure that is worse than the disease. Installing
> a Replacing package and then removing it, leaving the Replaced package
> broken, is an increasingly obscure corner case, precisely because
> Breaks+Replaces works smoothly enough that there's no reason not to use it,
> and under apt's guidance the Breaks will trigger an upgrade of the affected
> package ASAP.
It might not be too common but it happens often enough. Either due to
downgrades or broken packages that abort an upgrade. It makes removing a
package dangerous since dpkg offers absolutely no protection against it.
If dpkg doesn't keep track of the files then it should at least keep
track of the fact that files were replaced and mark the package as
incomplete and warn the user about the fact when the replacing package
is removed.
> In the rare event that a package is /not/ listed in Breaks, or is kept
> around anyway in a broken state, I don't agree that we should keep the
> replaced files around indefinitely to support this narrow use case.
Never thought about a Replaces without Breaks or Conflicts. Is there
even one such case in Debian?
>> Syntax of the "replaces" file:
>
>> The "replaces" file usualy contains one entry per line. Except that
>> lines starting with a single space are concatenated to the line before
>> with the space, but not the newline, removed. This is solely to support
>> filenames containing newlines.
>
>> Each entry has one of the following forms:
>
>> pkg /absolute/path
>> pkg (<< ver) /absolute/path
>> pkg (<= ver) /absolute/path
>
>> This means that the file </absolute/path> from the package <pkg> is to
>> be diverted or replaced. If a version is given the entry only applies if
>> <pkg> has version << 'ver' or <= 'ver'. Dpkg will rename the
>> </absolute/path> file from <pkg> to </absolute/path.dpkg-<pkg>> the same
>> way diversions function now.
>
>> The first form provides what dpkg-divert does now while the other two
>> provide what Replaces does.
>
>> To make replacing multiple files simpler the </absolute/path> could
>> contain wildcards like e.g. package foo-data containing
>
>> foo (<< 1.2-3) /usr/share/foo/*
>
> This is insufficient to handle the incompatible requirements of diversions
> and Replaces. The semantics of diversions are that only the *named* files
And a diversion should not use a wildcard.
> should be moved aside. The semantics of Replaces are that *any* files of
> the same name belonging to both packages should be replaced. You don't want
> to move aside every file matching a glob for Replaces handling, only those
> that are actually replaced; and for diversions handling, you don't want to
Which 'foo (<< 1.2-3) /*' could do. Only requirement is that wildcards
match files present in both packages and not all files in foo. Then you
get the behaviour you want.
> automatically assume a diversion is meant for each file collision.
As said above a diversion shouldn't be using a wildcard. Shouldn't need
to since the number of diversions is usualy verry small anyway. They
certainly shouldn't be using 'foo /*' and that would be the only way to
have a diversion for every file conflict.
The syntax for diversions and Replaces is distinct so dpkg can perfectly
know which of the two cases is ment and behave acordingly. But there
isn't even a difference in behaviour needed. A specifically named file
is always renamed and a wildcard matches files present in both packages.
> Declarative diversions are long overdue; but I see no value in conflating
> them with Replaces like this.
- allowing downgrades of replacing packages
- allowing abort of installs
- simplifying the dpkg logic by merging replaces and diversions into a
single case.
Even if you consider the first 2 as obscure cases the third should be
beneficial.
MfG
Goswin
Reply to: