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-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100721233349.gb2...@burratino

Reply via email to