[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: update-translator script for review

On Sun, Sep 19, 1999 at 02:22:16PM -0400, Roland McGrath wrote:
> > 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"?

In the command line in the update-translator script, so that this option is
always given to settrans. You wrote last year:

       If there are any active translators
       running as child filesystems of this translator, and you do not use
       -R, then even if there are no open files in the normal sense, those
       active translators will probably count as live clients and this
       translator will refuse to go away without -f.


       Note that a translator does not need to provide a directory to have
       child filesystems.  A translator providing a single-file filesystem
       can have another translator stacked on top of it (put there with
       `settrans -L').  In such a case, the -R issues above all still apply
       to this single child filesystem (and recursively to any children it
       might have, and its children's children).

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

Yes of course. So we can probably leave it to the package to provide "-R" if
> > 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.

Yes. What we are doing here is writing policy. Whatever comes out of this
discussion I will write up as a policy amendment to how treat Hurd
translators in Debian packages.
> 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.

Joey Hess implemented a configuration proposal by Wichert Ackermann which
allows to defer all questions to post installation as well as getting the
info from a (network-shared if you want) database. This will make unattended
installs possible, as well as sharing configurations over a farm. The tool
has several frontends, too (term, slang, gtk ...). We only have to make all
packages use this tool now.

> > 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?

Yes, I think so. I searched the policy and packaging manual and could find
no instructions for how to start/stop daemons during installation/upgrade
etc. We could investigate current packages, but most just stop it and
restart it, I think.

And, translators have sometimes different requirements (for example, it is
untested if exec can be replaced currently), so I don't know if we can
provide more than a guideline for this.

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

I don't know, that's why I asked. With "-k", at least the next time the
translator comes up gets the new options (which may be important if the
syntax changed!).

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

Yes, I figured that.
> > Or should we ask the user?
> You are asking me policy questions again.  

Yes, I know :) Seriously, this is because we are making policy here.
> > 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!

Argh, yes. We will always kill active and passive translator before deleting
the inode then.

> It might be desireable to use `-g' and just fail if the translator won't go
> away (i.e. refuse to remove the package).

Yes, failing is another option. However, no need for that if settrans gets
the "--kill-no-matter-what" option. Are there circumstances where leaving
the active translator in place is desirable even when all files (the
translator binary, supporting files) are removed?

I am sorry to ask all these questions, but it is not easy to figure out what
is the correct behaviour in all cases.

I hope some people on this list will do some tests with various combinations
of translators running (passive/active) and removing them! Everybody can do
this, so there's no excuse :)

`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

Reply to: