[FHS] helper scripts location

[Toshio Kuratomi]

On Fri, Jun 10, 2011 at 09:23:54PM +0200, Haïkel Guémar wrote:
> 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#USRLIBLIBRARIESFORPROGRAMMINGANDPA
> 
Ah -- in your original mesage you said that FHS explicitly blessed /usr/lib
as a place for shell scripts... which is not what this is saying.  However,
the description of internal binaries might fit the bill -- the FHS (and
Fedora's usage) of "binaries" is not always consistent.  Sometimes it is
equivalent to "object files" and other times it is equivalent to
"executables".  If we interpret this as "executable" then I think it works.

Note that this portion of the FHS is in direct conflict with the GNU Coding
standards which explicitly says not to use libdir in this way :-(

> 
> > 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.
>
Is this stuff a GNU configure compiled program?  Or does it have
a different build system?  (You could point me at the tarball/review request
and I could take a look).

> 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.
>
I just reread the thread where we discussed the pros and cons of libexecdir
and here's the take aways for when and why to use libexecdir:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/

1) Determine if the program cares about the wordsize of the helpers.
  * Are the helper programs mandatorily architecture independent or could
    they be arch dependent (ex: It's only convenient to write them in shell,
    the helpers could be written in C and compiled instead).
  * If it's only convenience, how likely is it that helpers would be written
    in a compiled language?  Would upstream consider it a bug if someone
    wrote a helper in a compiled language?
2.a) If the program does not care about the wordsize, then options are
     libexecdir or datadir.
  * Of the two, libexecdir is mandatory if architecture-specific helpers are
    allowed.
  * libexecdir is likely better even if architecture-specific helpers are
    not allowed as datadir is for data files and executable code is
    something of a stretch to classify that way.
  * Finally, see the last bullet of 2.b) for what the ramifications of using
    %{_libdir} are and whether that's acceptable in this specific case.
2.b) If the program does care about wordsize, then you need to use %_libdir
     which will either be /usr/lib or /usr/lib64 on Fedora.  The application
     (or config file) will need to be compiled/configured to know which path
     to use based on compilation (note that this may require a patch to
     upstream as well).
  * If the program does not care about wordsize but you put it into
    %{_libdir} anyway, you force helpers in separate packages/subpackages to
    be packaged arch-specific even though the only difference is the path
    pointed to by  %{_libdir}.  This is a pain but it's something that can
    be survived as long as people realize that they have to do this.  It
    doesn't have as significant an impact if all of the helpers are in the
    original package; helpers don't get added to by separate packages.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110610/7e37a545/attachment.bin