Steve Langasek <vor...@debian.org> writes: > I don't think it's a "whoops", but it is true that Breaks is asymmetric > and it's specifically the /broken/ package that is deconfigured when the > /breaking/ package is unpacked, and I think Policy should be clear about > this. (Yes, the fact that the package manager normally proceeds to > remove the broken package is an apt policy, not Policy.)
> So I think it's better to say: > This is a stronger restriction than <tt>Breaks</tt>, which just > prevents the package listed in the Breaks field from being > configured while the package with the Breaks field is present on > the system. > Avoids referring to packages listed in Breaks as 'broken', which it > seems we're trying to do even though we use the common English verbs > throughout Policy for the other relationship fields; and avoids the > ambiguous "is unpacked" where what we really mean is the much more bulky > "is in an unpacked state". The whole thing comes out pretty awkward for > all that, but I have no ideas on further improving it. I now have: <p> When one binary package declares a conflict with another using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than <tt>Breaks</tt>, which prevents the broken package from being configured while the breaking package is in the "Unpacked" state but allows both packages to be unpacked at the same time. </p> We do use "breaking" and "broken" elsewhere in Policy with respect to the Breaks header, so I felt comfortable using them here. -- 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