Re: update-translator script for review
> In the command line in the update-translator script, so that this option is
> always given to settrans.
No, definitely not.
> 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.
Ok. Well, I have been in favor of defining how to relate to hurd
translators as daemons (which we have mostly done here already), and then
having a single comprehensive debian policy for packaging of daemons.
> 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.
Can you give me a direct pointer to the documentation on how to use the new
tool in package scripts?
> 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.
Ok. Well, I think that it would be a good thing for debian policy to be
more clear on this.
> 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.
Each different daemon might have different requirements, depending on what
it does and how it is being used. This is not really particular to
translators per se. Some things will always be special cases, just like
installing a new linux kernel is, and perhaps exec will be one of these
(though I don't think it needs to be, we can fix that).
> > > 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!).
It's just the same as installing a new binary and init.d/rc?.d scripts,
without restarting the running daemon.
> Yes, I know :) Seriously, this is because we are making policy here.
Well, I would like to minimize the extent to which we are making
hurd-specific policy per se. For the case of translators, I think it maps
directly to the broader issue of daemons, and I would like to see a
consistent single policy across all debian systems that covers both daemons
and translators as a conceptual unit.
> > 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 don't know; it probably depends on the server in question. (For example,
with the current exec server, you can remove or replace all the binaries
and be fine until the next reboot if you leave the old active translator
running.)
> I am sorry to ask all these questions, but it is not easy to figure out what
> is the correct behaviour in all cases.
Indeed not. But it is reasonably straightforward to figure out the
definitions of how to relate translators to the general case of daemons.
It is then a general issue of policy (or needs of particular packages),
that hopefully you can figure out with the debian community and not ask me
to decide any of it. (You see, the best way to solve a problem is to
rigorously define it in terms of other people's problems, and then run away
quickly.)
Reply to: