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
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
