Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive

[Jonathan Nieder <jrnieder@gmail.com>]

retitle 592610 Clarify when Conflicts + Replaces et al are appropriate
quit

Hi Goswin,

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.

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.

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?

I wouldn't mind a policy "should" forbidding mutual C+R on the grounds
that they are confusing, even though they are a widespread practice.

Thanks for filing this.  I think it got forgotten.

Hope that helps,
Jonathan

[1] https://lists.debian.org/debian-ctte/2010/05/msg00010.html