Re: hurd does NOT need /hurd
>
>
>On Sun, May 19, 2002 at 07:16:08PM -0500, Adam Heath wrote:
>
>
>You are looking at completely the wrong properties. The issue is not
at all
>if a file is a binary, a text file, a picture or a marshmallow from outer
>space. Here are a few hints that should bring you on the right track:
>
>/bin: Executables that should be in the user's (including the
superuser's) PATH.
>/sbin: Executables that should be in the superuser's PATH, but not in the
> PATH of other user's.
>/libexec: executables that should not be in any user's path and that are
> started indirectly by other programs for their own purpose.
>/hurd: executables that can do something useful with the bootstrap
port to
> attach themself as Hurd servers to the file system, that
should not
> be in any user's PATH, and are started indirectly by settrans or
> the parent filesystem on the explicit request of the user.
>
I see you fighting but you never send new proposals, so I have a New
Idea (tm). First of all I will explain some things ; as said before :
/lib : contains libraries that are dynamically loaded by
programs linked against them.
/bin : programs that can be run from the command line.
/lib/modules : some sort of special library that has a 'modular'
aspect.
Since translators *really* are binaries that are /runnable/ from the
command line, they should be in /bin BUT it has been explained that
it doesn't fit because it is in user's $PATH. Therefore, as
translators have some modularity concept (hurd is ALL modular AFAIK)
why not putting them in /bin/modules ? (+ /hurd -> /bin/modules
for user convenience...). This is right because exec*p() doesn't
recurse subdirectories.
JC
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: