Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive
Jonathan Nieder <jrnieder@gmail.com> writes:
> In 2010, Goswin von Brederlow wrote:
>> in May there was a discussion about the right use of Breaks or
>> Conflicts as part of Bug#582423, e.g.
>> http://lists.debian.org/debian-ctte/2010/05/msg00012.html
> Policy §7.6.2 sayeth:
> | Second, Replaces allows the packaging system to resolve which package
> | should be removed when there is a conflict (see Conflicting binary
> | packages - Conflicts, Section 7.4).
> One reading of this would be that in the presence of Conflicts, Replaces
> represents a partial ordering of packages, indicating which should be
> removed in case of conflict. Seems useful enough. One consequence of
> this definition is that when A conflicts with and replaces B, B should
> not conflict with and replace A in turn, since the symmetric
> relationships would give no guidance in how to resolve the conflict.
Yes, that seems to be Ian's conclusion.
> Then it continues:
> | In this situation, the package declared as being replaced can be a
> | virtual package, so for example, all mail transport agents (MTAs)
> | would have the following fields in their control files:
> |
> | Provides: mail-transport-agent
> | Conflicts: mail-transport-agent
> | Replaces: mail-transport-agent
> |
> | ensuring that only one MTA can be unpacked at any one time.
> Here policy is recommending the same symmetrical C+R relationship it had
> just seemed to imply defeats the purpose of C+R.
Policy currently treats this as a special case distinguished by the
presence of Provides, but as discussed in that thread, that isn't a very
good assumption, since there are other reasons for wanting to add the
Provides than this case.
> Responding to this confusing passage, Ian Jackson wrote[1]:
> | If two packages Replaces/Conflicts/Provides the same virtual
> | package you can't just "dpkg -i" to swap between them. This is
> | demonstrated in Eugene's message on the 9th of May, and the test
> | case mentioned by Raphael does it.
> [...]
> | So which of spec or implementation is correct ? I think the
> | implementation is correct and the spec is wrong.
> The thread also contains some guidance about particular use cases,
> but first I guess we should resolve this question. Should packages
> A and B be allowed to ever both conflict with and replace each other?
Ian proposed a comprehensive replacement for what to use in the different
use cases we have, and I think that's a better approach. The point is to
make sure that we cover all our different use cases and can usefully
distinguish between them.
The key change is that the virtual package conflict drops Replaces, which
of course isn't what's in the archive right now and would require lots of
people change packages. Before we go down that path, I'd really like to
get confirmation from the dpkg developers that that's the correct thing to
do. I think that's the only real change from the current wording; the
rest is (useful) clarification.
Note that the point originally raised is that dpkg -i can't be used to
switch between packages implementing the same virtual package in a
mutually-exclusive fashion. Does the proposed solution actually fix that
problem?
Maybe someone could propose new language implementing the table discussed
in the above thread and then we could run it past the dpkg folks to make
sure that makes sense? I think the best wording approach would be to
describe the intent of Breaks, Conflicts, Provides, and Replaces in
isolation in their current sections, but then move all of the text about
how they work in concert to a new section that lays out the specific use
cases discussed and provides guidance for how to implement each one.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: