On Mon, May 20, 2002 at 03:30:15AM +0200, Marcus Brinkmann wrote: > On Mon, May 20, 2002 at 01:52:45AM +0100, Andrew Suffield wrote: > > > started indirectly by other programs for their own purpose. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > be in any user's PATH, and are started indirectly by settrans or > > > the parent filesystem on the explicit request of the user. > > ^^^^^^^^^^^^^^^^^^^^^ > > Kindly explain the difference between the indicated phrases. > settrans -a doesn't invoke any translator for its own purpose. It does only > start whatever the user is passing it on the shell. > settrans -a sets up a special environment for translators to run it (it sets > the bootstrap port). Then it just calls execv on the rest of the command > line. > Think of something like "/bin/sh -c "BOOTSTRAP=15 /hurd/ftpfs ..." > if you want. In this case, /bin/sh is not starting ftpfs for its own > purpose, but only starting what the user told it to start. I welcome you to take a look at the package 'freeswan', which contains an ipsec implementation for Linux. This package provides precisely one command in the system path -- /usr/sbin/ipsec -- whose primary purpose is to invoke a wide range of subcommands that exist as separate binaries. E.g., 'ipsec eroute', 'ipsec auto', u.s.w. Freeswan has gotten by just fine without the creation of a new toplevel directory for these commands; the supplemental binaries all exist in /usr/lib/ipsec/, which could be changed to /usr/libexec/ipsec/ and still fulfill the same purpose. By my reading, these tools meet all the criteria that you insist should set hurd translators apart in the filesystem: they are invoked at the explicit request of the user, they *can* be run directly but aren't necessarily useful if you do, and they have a corresponding utility that's used to set up the proper environment for them.[1] Would you argue that these tools also merit their own toplevel directory? It seems to me that using /hurd is a convenience (short pathname) rather than a technical necessity; and while I'm sure you find it more aesthetically pleasing to have these translators in their own toplevel directory, I think aj's suggestion of a default $TRANSPATH more than adequately meets the practical demands for it. Barring any /technical/ need for a new directory, the FHS already defines a place for these translators: /usr/lib/<subdir>/. Steve Langasek postmodern programmer [1] To be completely honest, the environment setup that has to be done in the ipsec case is minimal; the real motive for placing these tools in /usr/lib/ipsec/ is in order to provide modularity without causing namespace pollution -- though that in itself seems awfully similar to the Hurd's goals, IMHO.
Attachment:
pgpTXkJ1b3pME.pgp
Description: PGP signature