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
package ASAP.
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: