> 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).
