Hi again,
Guillem Jover wrote:
> Regardless of it being possible to call prerm by making the code in
> dpkg more complex/intelligent, the thing is if it would be the correct
> thing to do.
Yes, this is a useful question. Thank you for bringing it up.
First note that I don’t think this problem would come up often in practice.
Usually the package being replaced is an empty or almost-empty package, and
it is rare for such a package to need a prerm.
Most prerm scripts look something like this [1], but simpler.
#!/bin/sh
set -e
pkg=me
if type update-python-modules >/dev/null 2>&1
then
update-python-modules -c "$pkg.private"
fi
if test -x /usr/lib/emacsen-common/emacs-package-remove
then
/usr/lib/emacsen-common/emacs-package-remove "$pkg"
fi
if test -x "/etc/init.d/$pkg"
then
if test -x "$(which invoke-rc.d 2>/dev/null)"
then
invoke-rc.d "$pkg" stop || :
else
"/etc/init.d/$pkg" stop || :
fi
fi
if test -L "/usr/doc/$pkg"
then
rm -f "/usr/doc/$pkg"
fi
case "$1" in
remove|deconfigure)
update-alternatives --remove "$pkg" /usr/bin/whatever
esac
> Something to consider is that a disappearing package is
> just one for which its files have been completely taken over by another
> package, so arguably its contents do not get removed, they just change
> ownership, and no maintainer scripts do get called either on
> non-disappeared replaced files.
prerm is used for upgrades, too.
> But if there was a
> demonstrable need to run prerm script in this situation, I'd not see any
> problem in an evaluation on adding such call.
Waiting until it comes up does make some sense.
> Also dpkg will not disappear a package currently being
> depended on.
Ah, I didn’t realize this! That is very comforting to know and should
be helpful for transitions. It requires some front-end support to
work well, though: an obsolete package and any package that depends on
it have to be installed in a single dpkg run.
I will try it out.
Thanks,
Jonathan
[1] Except bash.prerm --- I don’t know what’s going on with that one.
automake and bsd-mailx do not remove alternatives when deconfiguring, but
I suspect they should. byacc removes alternatives on failed-upgrade.
I stopped reading there.
--
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/20100409061453.ga9...@progeny.tock
