Re: update-translator script for review
Hi,
On Sun, Sep 19, 1999 at 12:41:48AM -0400, Roland McGrath wrote:
> > What is missing now is a working policy how to call the script in the
> > postinst/prerm scripts. Especially which flags to pass to settrans to treat
> > the active translator right (should it be killed? should it be ignored,
> > etc).
>
> I have posted here before detailed descriptions of what the different
> options for using settrans are, relating them directly to
> killing/restarting other (non-translator) daemons.
Indeed, and this post will be my main reference when I start investigating
the different cases. The only reason I did not do it yet is because I want to
do all cases at once, and this will take a few hours (the different state of
packages can be very mind boggeling. You have to consider half-installed
packages, upgrading, downgrading, reinstallation and some other cases).
(For others, the message in question is "hurd init, translator upgrade" from
Wed, 19 Aug 1998, Message-Id: <199808192324.TAA05289@baalperazim.frob.com>)
> I think that there
> should be a consistent policy for translators (controlled with settrans
> and/or fsysopts) and other daemons (controlled with signals or whatever).
> Is there a clear debian policy regarding what the installation scripts
> should do about daemons being upgraded or removed that might already be
> running?
Yes, they are handled by scripts in /etc/init.d/foobar which are linked to
from /etc/rc?.d directories. The scripts accept start/stop/restart/reload as
options, and use teh start-stop-daemon program.
Well, if people care we can probably imitate some of this behaviour in the
update-translator script (a start-stop-translator script, if you want). But
I think it is easier to use settrans -a directly for this.
Some questions:
Should we use --recursive by default, or leave it to the package to decide
if stacked translators make sense on this node? [update-translator will
probably not manage file systems like ext2fs, so we only need to consider
stacked translators]
What should we do if we install a new translator, but the node exists
already (probably with a translator attached to it)? Should we act as if
we upgrade (see next item)? Or should we fail with an error code (causing
the package installation to abort and leaving the package in an unconfigured
state)? Or should we ask the user? [note that asking the user must be
minimzed for unattended installation]
I think we should leave it to the package maintainer to decide between the
following cases on upgrade:
"-k"eep active translator,
"-g"o away (ask nicely),
"-fg" force to go away.
Should we fall back to "-k" if "-gf" or "-g" is aksed for but fails?
Or should we look for the process and kill it if "-fg" is asked for and the
translator doesn't want to die?
Or should we ask the user?
On package removal, the script should be called with the additional options
"-fg", okay? (at least one easy case ;) [ in some cases, package may want to
prefer "-k" or "-g", but it should be noted that at least the purging issues a
"rm $node" and implies "-g". This can be circumvented by using a bogus $node
as argument.]
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Reply to: