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 <jrnie...@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.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100721233349.gb2...@burratino
