/usr/libexec

[H. Peter Anvin]

Russell Coker wrote:
> 
>>That being said, my point was that there doesn't seem to be any 32/64
>>separation for libexec, *and* it never made sense in the first place (it
>>was only added for bug-compatibility with BSD), so that's presumably why
>>it was removed.
> 
> If we have /usr/lib for 32bit SOs and /usr/lib64 for 64bit SOs, then it seems 
> clear to me that programs which are part of Postfix which may be either 32bit 
> or 64bit depending on which package is installed belong to neither category.  
> Therefore another place such as /usr/libexec seems appropriate.
> 
> The Gentoo people want /usr/lib/postfix for 32bit compiles 
> and /usr/lib64/postfix on 64bit compiles.  I believe that approach is totally 
> wrong and that /usr/libexec/postfix (as used in Fedora) is the better option.  
> If there's general agreement with that then we can move of requesting that 
> the FHS be changed to make the Red Hat practice be a standard in this regard.
> 

I think you're completely wrong.

Look at it this way: <random program> may not be sterilized for its 
internal interfaces, in respect of being cross-archictecture clean.  If 
you put it in libexec, then for exactly the reasons you mention you 
*HAVE* to handle mixed-mode.

Thus, although enforcing the separation may be *redundant*, it 
definitely not *harmful*, and might be beneficial.

For stuff like shell scripts, that are inherently cross-platform, that's 
  *exactly* what the share hierarchy is defined to be.

Either which way, libexec is useless.

	-hpa