[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

		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.

		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.

Does that look okay?

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: