Re: How to fix a broken postrm in upcoming releases
Dale Scheetz wrote:
>You can use the new package's preinst script to edit the postrm script of
>the old package (you have to edit the script in the dpkg info directory,
>as that is where dpkg goes to execute those scripts.
Maybe you can, but you shouldn't!
If the `postrm upgrade' call fails using the postrm from the old package,
dpkg will try to call `postrm failed-upgrade' using the postrm script
from the -new- package. Thus, you should never need to go grubbing
around in dpkg's private database. Remember, there's no guarantee that
the layout of /var/lib/dpkg will stay the same... It might even move
to /var/state/dpkg sometime, if anyone works out how to do it safely.
I posted some skeleton p{re,ost}{inst,rm} scripts to debian-mentors (or
was it debian-doc?) a few weeks ago; I'll post them again if you like.
I think they do a pretty good job of outlining all the possibilities you
can code for, but in a more easily digestible form than the packaging
manual's description.
Joey Hess wrote:
>Why not leave the hack in forever. I see no reason against it. Many of my
>packages have "do not ever touch or remove this section" areas in their
>maintainer scripts, to deal with issues that arose years ago.
I think this is generally good advice. However, for bugs in packages
which aren't critical, and where the bugs existed only for a short time
in an unstable package, I think you might as well remove the hack sometime
(possibly a long time) after the next stable release. I'd say you should
probably keep upgradability from all versions of your package which have
been part of a 'stable' release, though.
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: