Re: script for translator management
> I think we need a script for managing translators in /servers/ and a policy
> amandment to the Debian policy document, so all subsequent packages that
> provide translators for this directory have a consistent interface to the
> user.
That sounds good.
> As far as I can see, /servers/ is reserved for hooking in system
> translators, possibly in a subdirectory for grouping. Will it only be used
> by the Hurd itself, or is it true that additional translators (not in the
> main Hurd source) will hook in there? If the former is the case, a special
> script may be overkill.
I think other packages will install naming points in /servers, and install
translator programs in /hurd, just as they install programs in /bin. Since
these names are used by programs more than by people, and are never
path-searched, it probably makes sense for packages (some packages anyway)
to use subdirectories of /servers or /hurd as they do in /lib or /share.
Another thing to realize is that the /servers naming points indicate a set
of RPC protocols being made available, as opposed to being "private" to the
particular implementation of that protocol the way a package's installed
data files are private to the particular programs that use them (I don't
know what any particular ramification of this is, except maybe to argue
against package subdirectories in /servers after all). Conversely, /hurd
is just another place to plop a particular category of individual programs
(the main reason they're not just in /libexec is that we wanted our name to
stick out in the system a bit more).
> This only effects the passive translator. The active translator will left
> alone or killed or even forced to die, depending on additional options in
> the package script or on request of the user. The details have to be worked
> out (I have detailed information from Roland about how this works).
The details of determining what is running and shutting it down or
restarting it are some specific options to settrans. But the issue of what
you might want to do about a running translator when the translator program
and/or passive translator command line changes is the same as with a
package that updates daemons and/or daemons' startup (init.d) scripts
(translators are equivalent to daemons, and passive translator command
lines are equivalent to init.d scripts). It seems to me there should be a
consistent policy and set of options for handling both cases. Only the
mechanics of carrying it out differ.
> Comments?
Your scenarios for how to update translator settings sound right to me.
Reply to: