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