Re: Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder <jrnieder@gmail.com>]

Russ Allbery wrote:

> Initial bootstrap, like udebs, feels to me like
> something that's outside the intended scope of Policy.

Note to self: beg Neil Williams to help edit a document based on
multistrap.

> Jonathan Nieder <jrnieder@gmail.com> writes:

>>  * postrm does not get called until pre-dependencies for the new
>>    version are satisfied.  So I think it is impossible for
>>    pre-dependencies to be half-installed here.
>
> I believe, from what Ian said, that it's possible if the pre-dependencies
> of the old version are different than the pre-dependencies of the new
> version and the upgrade of the pre-dependencies failed.

The following is only about "postrm upgrade" and "preinst abort-upgrade".

I don’t follow; could you explain further?  The order of operations
during an upgrade when all goes well is something like this:

	<check pre-dependencies>
	preinst upgrade
	<unpack>
	postrm upgrade
	... unpack other things ...
	<satisfy dependencies>
	postinst upgrade

In particular, if postrm fails, then pre-dependencies will have
already been checked...

[...]
> What I have now, given the above, is:
> 
> 	    <item>
> 	      Called during error handling of an upgrade that failed after
> 	      unpacking the new package because the <tt>postrm
> 	      upgrade</tt> action failed.  The unpacked files may be
> 	      partly from the new version or partly missing, so the script
> 	      cannot not rely on files included in the package.  Package
> 	      dependencies may not be available.  Pre-dependencies will be
> 	      at least unpacked following the same rules as above, except
> 	      they may be only "Half-Installed" if an upgrade of the
> 	      pre-dependency failed.
> 	    </item>

... so although I doubt it would come up in practice, I believe the
exception described in the last three lines can be removed.

> I think I'll just say this:
> 
> 	    <item>
> 	      Called during error handling when <tt>prerm upgrade</tt>
> 	      fails.  The new package will not yet be unpacked, and all
> 	      the same constraints as for <tt>preinst upgrade</tt> apply.
> 	    </item>

Very nice.   That does clear things up.

>> For upgrade, the new package will be unpacked already, right?  Maybe
>> that should be discussed in the same paragraph as failed-upgrade.
>
> I'm hesitant to do so since it may lead people to assume that files or
> dependencies are available since they would be provided by the new
> version, without realizing that they can't anticipate what the new version
> of the package may do and the new version may have completely different
> files and dependencies.

So as a matter of policy, the old postrm should not rely on files
from the new package to avoid unduly impeding future changes in the
package.  Makes a lot of sense.

Thanks for your thoughtfulness.