Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
I don't actually see this. Could you point me to the quote and section?
"/usr/libincludes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts."
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMIN...
Additionally, the GNU Coding standards explicitly prohibit this (to
be clear
the GNU coding standards are not definitive for Fedora like the FHS is at
this time; I'm including the quotation to show what current best practices
are in this regard):
"""
‘libdir’
The directory for object files and libraries of object code. Do not install
executables here, they probably ought to go in ‘$(libexecdir)’ instead.
"""
At similar weight is the fact that some programs currently violate the GNU
Coding Standard recommendation here. However, I can't think of one of those
off the top of my head that is a unix-y program so those may be more
workaround than paradigm setters.
good to know
Preference-wise, I would say $LIBEXECDIR; settable at build time to
/usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
the best method here. Since we're talking scripts (architecture
independent), /usr/share may also make sense but I'm not a big fan of it.
If you can find me the piece of FHS that explicitly allows shell scripts in
/usr/lib I can figure out how that compares to using /usr/lib.
-Toshio
+1
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS, they won't move helpers from
/usr/lib which is FHS-compliant location.
I think that packaging guidelines should clarify this point, either we
enforce the use of /usr/libexec (and current packages should be fixed)
or we explicitely allow /usr/lib and/or /usr/share for helpers.
Personnally, i don't feel like burdening the reviewee with a non-FHS
compliant patch that has little chance to be upstreamed if it's not
mandatory.
H.