Bug#504880: Disambiguate "installed" for packages
On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:
> > Does dpkg provide any guarantee that the dependencies of the
> > pre-dependency are also present at this point? If it doesn't, I think
> > that should be considered a bug in dpkg, since you may be invoking a
> > command that links against a library whose soname has changed since the
> > last time the pre-dep package was configured. If it /does/ provide this
> > guarantee, I think it should be documented in Policy.
> I believe they can be in the same state as the pre-dependency itself for
> exactly the same reasons, no? Upgrades don't require deconfiguring
> packages that depend on the package being upgraded, so if you abort in the
> middle of upgrading a package the pre-dependency depends on, the
> pre-dependency is still present and configured on the system, so dpkg will
> treat the pre-dependency as satisfied.
The question is, if you upgrade a package which is a pre-dependency of
another package, are any *new* dependencies of that package guaranteed to be
unpacked before the package itself is?
This seems like a sensible thing for the package manager to enforce, but I
don't know if anything does so in practice.
> >> + 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>
> >> - </list>
> >> + </taglist>
> >> + </p>
> > This footnote is interesting to me because although it accurately
> > documents dpkg's behavior, I'm not sure what implications it has for how
> > packages should guard against this case. I think I've always ignored
> > this possibility in my maintainer scripts, and will continue to do so on
> > the grounds that any attempt to handle this gracefully is likely to
> > introduce much greater complexity (and therefore bugs) with very little
> > upside (when all is said and done, a package you were trying to remove
> > is still installed, so do we care if it configures successfully?)
> > If we can make a straightforward recommendation to maintainers for how
> > to handle this case, I think we should include that in the footnote.
> > Otherwise, if it shouldn't affect how we write maintainer scripts,
> > perhaps it's better not to have this footnote at all since it would only
> > lead to maintainers trying to be too clever and shooting themselves in
> > the foot?
> I think we should put it in the main text. I've now added, after the
> footnote and in the main text:
> The <prgn>postinst</prgn> should still attempt any actions
> for which its dependencies are required, since they will
> normally be available, but consider the correct error
> handling approach if those actions fail. Aborting
> the <prgn>postinst</prgn> action if commands or facilities
> from the package dependencies are not available is often the
> best approach.
> which I think is roughly what you're doing and what most people are doing
> and which I think is the generally best approach.
Sounds good to me, thanks.
> >> <p>
> >> The <tt>Depends</tt> field should also be used if the
> >> - <prgn>postinst</prgn>, <prgn>prerm</prgn> or
> >> - <prgn>postrm</prgn> scripts require the package to be
> >> - present in order to run. Note, however, that the
> >> - <prgn>postrm</prgn> cannot rely on any non-essential
> >> - packages to be present during the <tt>purge</tt>
> >> - phase.
> >> + <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> >> + require the depended-on package to be unpacked or
> >> + configured in order to run. In the case of <tt>postinst
> >> + configure</tt>, the depended-on packages will be unpacked
> >> + and configured first. (If both packages are involved in a
> >> + dependency loop, this might not work as expected; see the
> >> + explanation a few paragraphs back.) In the case
> >> + of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> >> + actions, the package dependencies will be at least
> >> + unpacked or "Half-Installed".
> >> + </p>
> >> </item>
> > I disagree with this change. If you are making use of non-essential
> > packages in your postrm, you *should* use the Depends: field; you just
> > *also* have to have a clean fallback plan if the dependency is not
> > satisfied when the postrm is called.
> > The normal use case is "whichever of the two packages is removed first
> > must clean up". While I can't think of a case where the cleanup
> > interface called from the postrm isn't already a dependency for other
> > reasons (e.g., for use in the postinst), I'd like this to be explicit
> > all the same.
> How about this?
> <p>
> The <tt>Depends</tt> field should also be used if the
> <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> require the depended-on package to be unpacked or
> configured in order to run, or if the dependend-on package
> is desirable for cleanup done by <prgn>postrm</prgn>. In
> the case of <tt>postinst configure</tt>, the depended-on
> packages will be unpacked and configured first. (If both
> packages are involved in a dependency loop, this might not
> work as expected; see the explanation a few paragraphs
> back.) In the case of <prgn>prerm</prgn> or
> other <prgn>postinst</prgn> actions, the package
> dependencies will normally be at least unpacked, but they
> may be only "Half-Installed" if a previous upgrade of the
> dependency failed. In the case of <prgn>postrm</prgn>,
> there are no guarantees, but the depended-on package is
> more likely to be available if the package declares a
> dependency (particularly for <tt>postrm remove</tt>).
> The <prgn>postrm</prgn> script must cleanly skip actions
> that require a dependency if that dependency isn't
> available.
> </p>
s/desirable/wanted/?
and s/dependend/depended/ :)
Seems ok to me. Better than Jonathan's proposed wording, which doesn't read
well because there's too much repetition.
I might also add at the end:
In such situations, the depended-on package should perform an equivalent
clean-up operation if it's the first package to be removed or purged.
But that may not be unambiguous enough to add any value here and I can't be
bothered to further tune the language right now; I don't think that's a
blocker and this bug has run quite long enough already.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: