Bug#578854: Should "Conflicts" be added to the "Replaces" example for package splitting?
Steve Langasek <vorlon@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: