On 2002.11.10 02:04 Jeff Bailey wrote:
On Sat, 2002-11-09 at 06:24, Robert Millan wrote: > Hence they need mkfs, fsck and other filesystem-related utilities > available in the /bin directory instead of /sbin. > Do you agree with that? In that case we should start fixing it > by filing a bug against package "general" and waiting for active > maintainers to fix their packages. I think I see two potential solutions to this: 1) /sbin should be added to every users path on i386-gnu systems. The concept of a binary that is completely unusable for regular users is almost unheard of for us. (The only few that come to mind is init, fdisk, and grub). 2) We could put ask for certain files to be made available in /bin by symlink and list them. In either case, it should probably be done as an annex to the FHS rather than going to the Debian maintainers. Tks, Jeff Bailey
I would raise a third possibility for discussion:3) that is moving all executables from /sbin to /bin then making /sbin a symlink of /bin. This would prevent the breaking of all the scripts which refer to /sbin/AppName directly, allow all users access to all normally administration only applications (presuming this is desirable) and would require no special Hurd specific modifications by the package maintainers. It also presents a similar approach to that of symlinking /usr to /
I would put forward some arguments for maintaining the current location and visibility of the /sbin executables: a) Compatibility between UNIXs: Applications (scripts or binary executables) written under Hurd which rely on applications being in the PATH where on other UNIXs they are not, would not run directly on the other UNIXs, making Hurd a bad development platform. b) If Hurd is used as a learning tool then the more conformance to the detail of FHS the better.
Just some thoughts Chris Gibson