Bug#504880: Disambiguate "installed" for packages

[Russ Allbery <rra@debian.org>]

Steve Langasek <vorlon@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>