prerm for disappearing packages?

[Jonathan Nieder <jrnieder@gmail.com>]

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.