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/ [email protected] [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
