Bug#504880: Disambiguate "installed" for packages
Thank you very much for the detailed review!
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:
>> <p>
>> + What follows is a summary of all the ways in which maintainer
>> + scripts may be called along with what facilities those scripts
>> + may rely on being available at that time. Script names
>> + preceeded by <var>new-</var> are the scripts from the new
>> + version of a package being installed or upgraded. Script names
>> + preceeded by <var>old-</var> are the scripts from the old
>> + version of a package that is being upgraded to a new version.
>> + </p>
> Spelling: “preceeded” should be “preceded”.
Fixed.
> The term “upgraded” is a bit ambiguous in situations where a package is
> being downgraded or an upgrade is being rolled back. Probably the
> context makes the meaning obvious in any particular instance, though.
I now have:
<p>
What follows is a summary of all the ways in which maintainer
scripts may be called along with what facilities those scripts
may rely on being available at that time. Script names preceded
by <var>new-</var> are the scripts from the new version of a
package being installed, upgraded to, or downgraded to. Script
names preceded by <var>old-</var> are the scripts from the old
version of a package that is being upgraded from or downgraded
from.
</p>
to mention downgrades. The meaning of new and old of course doesn't
change even during error unwind, but hopefully that's still clear from
context.
>> + Only essential packages and pre-dependencies
>> + (<tt>Pre-Depends</tt>) may be assumed to be available.
>> + Pre-dependencies will either be configured or will be
>> + "Unpacked" or "Half-Configured" but previously had been
>> + configured and was never removed.
> The second sentence is starting to get wordy. Maybe:
> Only essential packages and pre-dependencies
> (<tt>Pre-Depends</tt>) may be assumed to be available.
> Pre-dependencies will be unpacked and have been
> configured after they were last removed[1].
> [1] During an upgrade, a package listed in
> <tt>Pre-Depends</tt> may be "Unpacked" or "Half-Configured"
> in its new version, but only if a previous version was
> configured completely and the package has not been
> removed since then.
I don't want to move state information into a footnote. Here's a new
version that is hopefully a bit cleaner:
<item>
The package will not yet be unpacked, so
the <prgn>preinst</prgn> script cannot rely on any files
included in its package. Only essential packages and
pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
available. Pre-dependencies will be at least unpacked.
They may be only unpacked or "Half-Configured", not
completely configured, but only if a previous version of the
pre-dependency was completely configured and the
pre-dependency had not been removed since then.
</item>
> I doubt these rules apply to the initial bootstrap. Is that worth
> mentioning somewhere?
I don't think so. Initial bootstrap, like udebs, feels to me like
something that's outside the intended scope of Policy.
>> + Called during error handling of an upgrade that failed after
>> + unpacking the new package because the
>> + old <prgn>postrm</prgn> failed during the upgrade action.
> Getting wordy. Maybe:
> Called to recover from an upgrade that failed after
> unpacking the new package because the old <prgn>postrm</prgn>
> failed.
The point that I'm trying to get at here is that it's specifically postrm
upgrade that failed. I reworded it some -- see below.
>> + Depending on the severity and nature of the error, the
>> + package's dependencies, including pre-dependencies, may be
>> + only "Half-Installed" or "Unpacked" and are not necessarily
>> + configured, and the files for the old package may not yet be
>> + unpacked.
> * Not sure what the phrase “Depending on the ... nature of the
> error” is supposed to be getting at here. Is this just to say
> the package might not have been fully installed yet? I would
> leave the clause out.
Reworded to leave that out.
> * Can’t (new) dependencies be missing altogether? I thought part of
> the point of the pre-depends/depends distinction was that the
> latter does not constrain unpacking order.
I believe unpacking order is still constrained, but the unpacked packages
don't have to be fully configured before the depending package is
unpacked. With Pre-Depends, the dependency is fully configured before the
depending package is unpacked.
However, you're right, I don't think anything guarantees that the
dependencies are available at this point, only the pre-dependencies.
> * 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.
> So:
> Pre-dependencies for the old and new versions of the package
> will be at least unpacked and have been configured after they
> were last removed[1].
> The package's dependencies (<tt>Depends</tt>) in the new and
> old versions are not guaranteed to be satisfied, and files
> from the old and new versions of the package are neither
> guaranteed to be present nor not present in the file system.
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>
>> + <item>
>> + The files contained in the package will be unpacked. All
>> + package dependencies will at least be "Half-Installed" and
>> + will have previously been configured and not removed.
>> + However, depending on the nature and severity of the error,
>> + dependencies may not be configured or even fully unpacked.
>> + </item>
>> + </taglist>
>> + </p>
> An example of when dependencies can be half-installed would be
> helpful.
I now have:
<item>
The files contained in the package will be unpacked. All
package dependencies will at least be "Half-Installed" and
will have previously been configured and not removed.
However, dependencies may not be configured or even fully
unpacked in some error situations.<footnote>
For example, suppose packages foo and bar are installed
with foo depending on bar. If an upgrade of bar were
started and then aborted, and then an attempt to remove
foo failed because its <prgn>prerm</prgn> script failed,
foo's <tt>postinst abort-remove</tt> would be called with
bar only "Half-Installed".
</footnote>
</item>
>> + <item>
>> + The package whose <prgn>prerm</prgn> is being called will be
>> + at least "Half-Installed". All package dependencies will at
>> + least be "Half-Installed" and will have previously been
>> + configured and not removed. If there was no error, all
>> + dependencies will at least be unpacked, but these actions
>> + may be called in various error states where dependencies are
>> + only "Half-Installed".
>> + </item>
>> +
> Any package we call prerm for is halfconfigured or better, so all
> of its dependencies were fully satisfied at some point.
Right, that's the point of the second sentence.
> Like before, it is probably worth mentioning that dependencies can
> only be halfinstalled in this case due to a partial upgrade, not a
> partial install.
Added a note to that effect.
>> + <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
>> + <var>old-version</var></tag>
>> + <item>
>> + Called during error handling when <tt>prerm upgrade</tt>
>> + fails. The new package will not yet be unpacked. Since
>> + this is the first action taken during a package upgrade,
>> + only essential packages and pre-dependencies may be relied
>> + on. Pre-dependencies will either be configured or will be
>> + "Unpacked" or "Half-Configured" but previously had been
>> + configured and was never removed.
>> + </item>
> Why can’t one rely on dependencies here, too?
Look at when prerm failed-upgrade is called. If one is upgrading package
foo to a newer version, the very first thing that happens, long before the
new package is unpacked, is that the old prerm script is called with an
argument of upgrade. If this fails, the preinst script for the new
package is called with the argument failed-upgrade. Since this is early
in the unpack stage, there are no guarantees about unpack order.
If prerm failed-upgrade could rely on dependencies being unpacked, so
could preinst, since preinst is called later in the process. The
situation for prerm failed-upgrade is identical to the situation for
preinst. 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>
>> + <item>
>> + The <prgn>postrm</prgn> script is called after the package's
>> + files have been removed. The package
>> + whose <prgn>postrm</prgn> is being called may have
>> + previously been deconfigured and only be unpacked, at which
>> + point subsequent package changes do not consider its
>> + dependencies. Therefore, all <prgn>postrm</prgn> actions
>> + may only rely on essential packages and cannot assume that
>> + the package's dependencies are available.
>> + </item>
> Yes.
> 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.
The right rule here is to not rely on anything other than essential
packages.
I did add "or replaced" at the end of the first sentence there.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: