Re: Bug#504880: Disambiguate "installed" for packages
Russ Allbery writes ("Re: Bug#504880: Disambiguate "installed" for packages"):
> The current wording does cover the cases of the other scripts. What my
> current proposed wording says, summarized, is:
...
This is a very helpful way of presenting it.
> postrm (all functions except purge):
> All dependencies will be configured. (Given that prerm doesn't
> require that they be configured, this is odd -- Raphael, can you
> confirm this is really what you intended?)
I don't think this is right.
postrm in principle can be run without the dependencies even
installed. For example, the dependencies might have been removed
after the package was deconfigured (ie, put into state `unpacked') but
before it was removed.
So postrm cannot make any more assumptions than preinst. (Also postrm
is sometimes used to undo preinst.)
> postrm purge:
> Only essential packages may be relied on.
So I think this is always true of postrm.
> prerm (all functions):
> All dependencies will be unpacked. They may or may not be
> configured.
...
> postinst abort-upgrade
> postinst abort-remove
> postinst abort-deconfigure
I don't think you have analysed this quite correctly.
The key point is that unpacking a package is not considered to break
dependencies. Ie, if A -Depends-> B and both are `installed', dpkg
will allow a new version of B to be unpacked (thus moving B from
`installed' through various even-worse states to `unpacked'). This is
not regarded as requring A to be deconfigured.
Thus the criterion for A being `installed' is not that B is also
`installed', but rather that B was `installed' at some previous point
and has not been removed (or replaced with an inappropriate version)
since.
But the prerm is only called if the package was originally in state
`installed' or `half-installed', which means that this condition is
satisfied whenever the prerm is called.
So in summary:
* while it's true that the dependencies may not be configured,
they will have been configured more recently than they were
removed (indeed this is the same condition as for Pre-Depends)
* the depencies might be in a worse state than `unpacked'; they
might be in `half-installed' due to an upgrade unpack which
had previously failed (dpkg tries to avoid this situation but
it can occur); in principle the on-disk files might even be
a mixture from the two versions of the dependency, although
dpkg tries hard to avoid this
postinst abort-* are error-unwinding cases for the prerm. Thus they
may be called in any situation when the prerm may be called.
> What I'd like at this point are answers from the dpkg developers about
> dpkg's behavior in the following areas:
>
> 1. Are all package dependencies guaranteed to at least be unpacked at the
> time that postinst configure is called, even if there are circular
> dependencies?
Yes.
> 2. Is a package guaranteed that its dependencies will still at least be
> unpacked when its prerm upgrade is called, even if the new package
> we're in the process of installing has dependencies that cannot be
> satisfied at the same time as the dependencies of the currently
> installed package?
Yes. The new version's dependencies are irrelevant, just as the
dependencies are irrelevant for the unpack of a
not-previously-installed package.
> 3. The same question as (2) for prerm deconfigure.
Yes.
During any call to the prerm, all dependencies are satisfied at least
as much as they would be for the preinst if they were Pre-Depends.
This is not done explicitly by checking in the code, but is a
consequence of the other restrictions, which ensure that the prerm
will be called before that dependency condition is broken.
> If the answer to all of the above questions is yes, then I think we can
> say that package dependencies are always at least unpacked when postinst
> configure, prerm remove, and prerm deconfigure are called,
Yes.
> and package dependencies are always configured when postrm remove
> and postrm disappear are called.
No, the postrm is not entitled to assume anything very much.
> Package dependencies are also always configured when postinst
> configure is called unless there are circular dependencies. Then I would
> just say that there are no guarantees for the other postinst, prerm, and
> postrm actions.
The postinst abort-* activities work the same way as prerm.
Ian.
Reply to: