libexecdir and i686-pc-linux-gnu-dir

Björn Lindberg d95-bli at
Thu Mar 22 07:10:02 PST 2001

On Wed, 21 Mar 2001, Gerard Beekmans wrote:

> > Oh, but there is a reason for this. /bin directories will typically
> > be a part of someone's PATH. Since internal libraries aren't meant to
> > be executed directly, they shouldn't reside in PATH directories, thus
> > clogging up the namespace.
> I know the reason, I personally, and forgive me to be blunt and my languge,
> don't give a shit. If I'm not supposed to execute those binaries then I won't
> execute them. As to clogging up my namespace, well we may be talking about 2
> binaries here, hardly 'clogging up'.
> Yes, when it comes to large multi-user systems it wouldn't be a good idea,
> but that's why I'm talking about 'personally' ie. on my own computer. And
> running pt_chown yourself doesn't cause any harm.

Ok, now I understand where you are coming from. The FHS is, of course
designed for use in large multi-user systems as well as smaller
systems. When you said (paraphrase): "On this point I disagree with
the FHS", I interpret that as that you don't agree the FHS should
include this requirement. Now you are saying that you basically agree
with the FHS, but that you don't want to use it on your computers.
Then I agree with you.

Use the directory structure you want on your lfs-system. You could
even have a /Program Files directory instead of /usr/bin... :-)

But seriously, I still think that the FHS rationale for keeping
internal binaries in /usr/lib is better than you arguments.

Oh BTW, some time ago I installed openSSH as per the hint. I noticed
that it needs a --libexec=<directory of choice> switch to avoid
creating a libexec-dir. Perhaps the hint could be updated?


Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list