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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
