Re: Bug#504880: Disambiguate "installed" for packages
Steve Langasek <vorlon@debian.org> writes:
> On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:
>> I believe they can be in the same state as the pre-dependency itself
>> for exactly the same reasons, no? Upgrades don't require deconfiguring
>> packages that depend on the package being upgraded, so if you abort in
>> the middle of upgrading a package the pre-dependency depends on, the
>> pre-dependency is still present and configured on the system, so dpkg
>> will treat the pre-dependency as satisfied.
> The question is, if you upgrade a package which is a pre-dependency of
> another package, are any *new* dependencies of that package guaranteed
> to be unpacked before the package itself is?
> This seems like a sensible thing for the package manager to enforce, but
> I don't know if anything does so in practice.
I think I've lost track of all the packages here and am not entirely sure
what you're describing, but regardless we should probably move this part
of things into #593177, which is specifically about this.
> s/desirable/wanted/?
> and s/dependend/depended/ :)
> Seems ok to me. Better than Jonathan's proposed wording, which doesn't
> read well because there's too much repetition.
> I might also add at the end:
> In such situations, the depended-on package should perform an equivalent
> clean-up operation if it's the first package to be removed or purged.
> But that may not be unambiguous enough to add any value here and I can't
> be bothered to further tune the language right now; I don't think that's
> a blocker and this bug has run quite long enough already.
I'm going to bail on that because of the length of the bug; I'd really
like to get this merged, since it's blocking resolving a few other bugs
that touch the same areas of wording.
I think it does read slightly better as two paragraphs. Here's what I
have now:
<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 normally be at
least unpacked, but they may be only "Half-Installed" if a
previous upgrade of the dependency failed.
</p>
<p>
Finally, the <tt>Depends</tt> field should be used if the
depended-on package is needed by the <prgn>postrm</prgn>
script to fully clean up after the package removal. There
is no guarantee that package dependencies will be
available when <prgn>postrm</prgn> is run, but the
depended-on package is more likely to be available if the
package declares a dependency (particularly in the case
of <tt>postrm remove</tt>). The <prgn>postrm</prgn>
script must gracefully skip actions that require a
dependency if that dependency isn't available.
</p>
Does that look okay?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: