Re: update-translator script for review
> 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.
That is not what I meant. That is the mechanism by which a daemon is
started running or a running daemon is affected. That mechanism is
different for translators. I am talking about the policy of which of these
actions (regardless of mechanism) to take when installing/upgrading/removing
a package.
> 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]
I am not sure exactly what the question is here; what do you mean "by default"?
Stacking translators is definitely not what you want for most cases.
I am imagining that the translators installed by packages will mostly be
service naming points (such as /servers/*).
> 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]
My whole point was that how to deal with these situations is something that
debian policy should specify. This is not greatly different from any other
preexisting file that installing a package might clobber.
Personally, I hate having it ask the user (I won't tell you how many times
now I have left dpkg running overnight and come back in the morning to see
it waiting at some prompt with 99% of the work still left to do). I wish
all packagers would refuse to clobber unknown files of any kind, but that
is a policy issue.
> 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.
Is it left to the package maintainer to decide what to do about a daemon also?
> Should we fall back to "-k" if "-gf" or "-g" is aksed for but fails?
In fact, `-g' asks nicely and `-gf' asks "pretty please", but nothing in
fact forces an uncooperative translator. (I think we should perhaps change
this.) Consider goaway equivalent to sending a SIGTERM to a daemon; if the
daemon doesn't die after that, do you start a new one or do you leave the
old one running? -k leaves the old one running.
> Or should we look for the process and kill it if "-fg" is asked for and the
> translator doesn't want to die?
I hesitate to suggest this. It is error-prone, because there is no sure
way to know which process it is. I'm inclined to think we should beef up
settrans with a more forceful option.
> Or should we ask the user?
You are asking me policy questions again.
> 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.]
Note that `settrans -g NODE' will make the translator go away happily if
it's running, but `rm NODE' will get EISDIR if the translator wouldn't mind
going away but is providing a directory as the visible file. So I would
say always clear the translator before removing the node. Also, it depends
on `rm' not doing `stat' or anything on the node before trying to unlink
it--if `rm' does call `stat' or suchlike on the node, it will start up the
passive translator!
It might be desireable to use `-g' and just fail if the translator won't go
away (i.e. refuse to remove the package).
Reply to: