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-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vaqx6w3....@windlord.stanford.edu
