On Mon, Jul 21, 2003 at 02:19:15PM +0200, Piotr Roszatycki wrote:
> On Thu, 17 Jul 2003, Piotr Roszatycki wrote:
>
> > I'd like to close bugs #38584, #181130. I just want to know how to call
> > update-alternatives in maintainer's scripts. Should be only with 'configure'
> > state for postinst and 'remove' for postrm? What is official policy for
> > alternatives?
>
> Ok, so what is correct?
>
> In postinst:
>
> if [ "$1" == "configure" ]; then
> update-alternatives --install ...
> fi
>
> or just:
>
> update-alternatives --install ...
From section 6.4 of the Debian Policy Manual, version 3.6.0:
* postinst configure most-recently-configured-version
* old-postinst abort-upgrade new-version
* conflictor's-postinst abort-remove in-favour package new-version
* deconfigured's-postinst abort-deconfigure in-favour
failed-install-package version removing conflicting-package version
You should therefore only run this update-alternatives command where it
makes sense to do. That means understanding the $1 passed to your
script.
Does it make sense when configuring the package normally? Probably
so.
Does it make sense when re-running the postinst after a failed attempt
to upgrade the package? Probably so.
Does it make sense when re-running the postinst after a failed attempt
to install a conflicting package? Probably so.
Does it make sense when re-running the postinst after a failed attempt
to deconfigure this package in favor of a conflicting one? Probably
so.
In my personal experience, limited to packages of the complexity of
XFree86, you generally do want to do the same things for all four of
these cases.
However, that doesn't mean it's not smart to understand how your
maintainer script may be called. Also, we may extend the syntax of the
arguments to the postinst script in the future.
> In prerm:
>
> if [ "$1" == "remove" ]; then
> update-alternatives --remove ...
> fi
>
> or just:
>
> update-alternatives --remove ...
>
> What is the best common practices?
Well, let's run through the cases as we did above.
* prerm remove
* old-prerm upgrade new-version
* new-prerm failed-upgrade old-version
* conflictor's-prerm remove in-favour package new-version
* deconfigured's-prerm deconfigure in-favour package-being-installed
version removing conflicting-package version
You should only run this update-alternatives command where it makes
sense to do. That means understanding the $1 passed to your script.
Does it make sense when removing the package? Probably so.
Does it make sense when upgrading the package to a newer version?
Probably so. (If the upgrade is aborted, not doing this would leave bad
symlinks on the system, which could have grievous consequences depending
on what you try to do.)
Does it make sense when upgrading the package to a newer version, but
the old version's prerm script was buggy or threw an error? Probably
so.
Does it make sense when replacing this package with another which
conflicts with it? Probably so.
Does it make sense when deconfiguring this package because it depends on
a package which is being replaced by a conflicting one? Possibly. It
depends on whether you expect the resource under management by
update-alternatives to fail if a package you depend on goes missing for
a little while (while dpkg changes the system).
I think it's a sound practice to do real work within a maintainer script
when you understand what arguments your script has been passed.
(I do not, however, claim that the XFree86 packages perfectly embody
this advice.)
--
G. Branden Robinson | Men are born ignorant, not stupid.
Debian GNU/Linux | They are made stupid by education.
branden@debian.org | -- Bertrand Russell
http://people.debian.org/~branden/ |
Attachment:
pgpaBMbyDRiVQ.pgp
Description: PGP signature