Bug#504880: Disambiguate "installed" for packages
Hi Jonathan,
On Sun, Aug 08, 2010 at 07:27:44PM -0500, Jonathan Nieder wrote:
> > Does dpkg provide any guarantee that the dependencies of the pre-dependency
> > are also present at this point?
> Sure: that is part of what it means to configure a package.
> Except *new* dependencies of an upgraded pre-depedency may not be
> present. This is part of the philosophy behind pseudo-essential
> packages generally using pre-depends for one release when they
> acquire new dependencies.
> > 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.
> Should I file a policy bug to clarify this?
I think that would be a good idea, yes - thanks!
> [...]
> >> + The <prgn>postrm</prgn> script is called after the package's
> >> + files have been removed or replaced. 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.
> [...]
> > True as written, but less helpful than it should be. There are a number of
> > cases where postrm scripts still need to *try* to invoke non-essential
> > functionality, and fail gracefully if it's unavailable
> Yes, that is worth mentioning. Actually it has very little to do with
> dependencies.
> For example, many packages only use “Suggests: doc-base” but have
> snippets like the following in prerm:
> # Automatically added by dh_installdocs
> if [ "$1" = remove ] || [ "$1" = upgrade ] && \
> which install-docs >/dev/null 2>&1; then
> install-docs -r whatever
> fi
> Maybe a footnote would be appropriate? Something along these lines:
I think it needs to be stronger than a footnote; what we're describing here
is one of the primary uses of postrm scripts.
> This is not intended to excuse packages from the obligation
> to clean up after themselves when they have placed some
> state in a non-essential package's care. The usual strategy
> for that is as follows:
This language seems pretty good.
> If you have a package that manages a configuration file
> with ucf, you must call "ucf --purge" from postrm if ucf is
> present on the system at that point. If ucf is not present,
> then the configuration file is in its care and will be
> removed when ucf is purged.
I think Russ's example is better than this textual description of the
process.
> >> @@ -4588,12 +4651,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
> >>
> >> <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.
> >> + <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> >> + require the depended-on package to be unpacked or
> >> + configured in order to run.
> [...]
> > I disagree with this change.
> [...]
> > 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.
> Given the explanation above, do you still think Depends should be used
> this way?
Yes, absolutely! If there's some operation that /should/ be done in the
postrm if at all possible, and we want to give ourselves the best possible
odds that we'll be able to, a Depends is the way to achieve that. The
package manager won't guarantee the dependency is installed at postrm time,
but this is as good as we can get.
Consider this sequence:
foo install registers a file with ucf
foo is removed
ucf is removed
foo is purged; because ucf is no longer installed, the config file
information is kept in place
foo is reinstalled, pulling in ucf - and the old config file is restored,
contrary to the definition of 'purge'
Is ucf misbehaving by not removing its state on package removal? I can't
say so; I think it's behaving the way Policy expects it to. Likewise, foo
isn't wrong for failing to remove its config data from ucf on package
removal (i.e., in prerm). So both packages are perfectly policy-compliant,
but in this corner case the outcome is incorrect.
It'll always be possible to end up with such a sequence as a result of
manual action on the part of the user, but I think we should do our best to
avoid landing a user in this situation automatically. Having foo Depends:
ucf, and ensuring the package manager removes packages in reverse dependency
order where possible (which I believe is currently the case), is the best
way to accomplish this. It won't guard against the "remove, then purge
later" situation, but it will help for cases where the deregistration of
data is done in postrm remove.
--
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: