Bug#504880: Disambiguate "installed" for packages
Jonathan Nieder <jrnieder@gmail.com> writes:
>> <p>
>> - For this reason packages in an installation run are usually
>> - all unpacked first and all configured later; this gives
>> - later versions of packages with dependencies on later
>> - versions of other packages the opportunity to have their
>> - dependencies satisfied.
>> + Since <tt>Depends</tt> only places requirements on the
>> + configuration step, packages in an installation run are usually
>> + all unpacked first and all configured later. This makes it
>> + easier to satisfy all dependencies when multiple packages are
>> + being upgraded.
>> </p>
> The new second sentence is less specific than the anthropomorphizing
> original. Intended?
I found the original awkward and hard to puzzle out. How about this:
<p>
Since <tt>Depends</tt> only places requirements on the order in
which packages are configured, packages in an installation run
are usually all unpacked first and all configured later. This
allows multiple packages to be upgraded in one unpack and
configure step even if some packages being upgraded have
versioned dependencies on the upgraded versions of other
packages involved in the installation run.
</p>
which hopefully re-adds the specific information.
> [...]
>> - The <tt>Depends</tt> field thus allows package maintainers
>> - to impose an order in which packages should be configured.
>> </p>
> Is this removal intended?
Yes, it seems to just duplicate the first sentence of the paragraph above
and the description of Depends later on.
> [...]
>> @@ -4588,12 +4642,16 @@ <sect id="binarydeps">
>>
>> <p>
>> The <tt>Depends</tt> field should also be used if the
>> - <prgn>postinst</prgn>, <prgn>prerm</prgn> or
>> - <prgn>postrm</prgn> scripts require the package to be
>> - present in order to run. Note, however, that the
>> - <prgn>postrm</prgn> cannot rely on any non-essential
>> - packages to be present during the <tt>purge</tt>
>> - phase.
>> + <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
>> + require the package to be unpacked or configured in order
>> + to run.
> Huh?
> postinst in the normal case requires the package being installed to be
> unpacked and all its dependencies to be configured. prerm requires the
> package being removed to be halfconfigured.
> I think part of my confusion is because:
> * this item is supposed to be about what the Depends field can
> be used to accomplish, not what requirements postinst and
> preinst have;
> * before, “the package” meant the package depended on, but now
> it means the package being installed or removed.
I think you're completely misreading the new paragraph. I added another
"depended-on" to the wording to hopefully make it clearer. How's this,
which also addresses the fact that the rules are different for postinst
configure than for the other cases?
<p>
The <tt>Depends</tt> field should also be used if the
<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
require the depended-on package to be unpacked or
configured in order to run. In the case of <tt>postinst
configure</tt>, the depended-on packages will be unpacked
and configured first. (If both packages are involved in a
dependency loop, this might not work as expected; see the
explanation a few paragraphs back.) In the case
of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
actions, the package dependencies will be at least
unpacked or "Half-Installed".
</p>
>> <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 installed on the system at the
>> + refuse to allow them to be unpacked on the system at the
>> same time. This is a stronger restriction than <tt>Breaks</tt>,
>> which just prevents both packages from being configured at the
>> same time. Conflicting packages cannot be unpacked on the
> Whoops.
> This is a stronger restriction than <tt>Breaks</tt>,
> which only prevents the broken package from being configured at
> the same time as the breaking package is unpacked.
I believe what I wrote is more correct than what you wrote. What do you
think is wrong about it which prompts the "whoops"? Breaks allows both
packages to be unpacked at the same time, but only one of the two packages
can be configured at the same time. Configuring one package will result
in deconfiguring the other. (At least. I think under normal
circumstances the broken package is then removed, although I'm not sure
since Policy never says that. All Policy says will happen is that it will
be deconfigured.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: