Steve Langasek <vor...@debian.org> writes: > If you install 'a' version 1, then install 'b' version 2, then /remove/ > 'b' version 2, 'a' remains in 'configured' state but is now missing some > files because ownership of the files transferred to package 'b'.
> If Package: b declares Conflicts: a (<< 2) at the same time, this > reliably avoids this scenario by forcing an upgrade of 'a'. > But it's also overly aggressive, since it forces 'a' version 2 to be > unpacked first, *before* unpacking package 'b' - in which case, what do > we need the Replaces: for at all? This is really a workaround for the > fact that Breaks: didn't exist at the time this part of Policy was > written. With Breaks: a (<< 2) and Replaces: a (<< 2), we can force the > upgrade of 'a' in tandem with 'b', but without imposing the unpack > ordering constraints that cause such big problems for dist-upgrades. Ah, aha. (This should definitely be explained in Policy, at least in a footnote.) So that implies that, for the typical case of moving a file from one package to another, we should use Replaces/Breaks, and reserve Conflicts for actual file conflicts between unrelated packages (such as libkrb5-dev and heimdal-dev). Is that correct? I see some discussion in the bug log about problems in dpkg that cause it to possibly do the wrong thing with Replaces/Breaks and downgrades, but so far as I can tell from the follow-up from Guillem, the remaining issues aren't really specific to Breaks and also apply to Conflicts. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org