Re: RFC: Proposal to combine diversions and Replaces into DEBIAN/replaces
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
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.
> 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
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
automatically assume a diversion is meant for each file collision.
Declarative diversions are long overdue; but I see no value in conflating
them with Replaces like this.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/