Re: [PATCH 1/7] bitbake.conf: fix definition of ${libexecdir}

[Saul Wold <sgw@linux.intel.com>]

On 04/29/2013 10:03 AM, Enrico Scholz wrote:
> "Burton, Ross" <ross.burton-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
>>> Things *are* expected to move around.  E.g. /usr/lib/openssh/sftp-server
>>> becomes /usr/lib/sftp-server now.
>>
>> Right, so don't use Debian as a rationale for this approach.
>
> Debian defines libexecdir to be /usr/lib (+multiarch).  It might set
> sometimes per-package '--libexecdir=${libexecdir}/<package>' configure
> options, but libexecdir is always /usr/lib there.
>

As I read though this, a couple things I noted from some of the 
available information, the GNU Directory section you quoted earlier 
actually suggests a package-name directory should be included.

   The definition of ‘libexecdir’ is the same for all packages, so you
   should install your data in a subdirectory thereof. Most packages
   install their data under $(libexecdir)/package-name/, possibly within
   additional subdirectories thereof, such as $(libexecdir)/package-
   name/machine/version.

And as you pointed out below, the FHS also touches on having a 
sub-directory for applications to use for non-user object and internal 
binaries (like plugins).


>
>> $ ls /usr/lib/openssh/
>> sftp-server  ssh-keysign  ssh-pkcs11-helper
>>
>> For reference, on Fedora this binary is /usr/libexec/openssh/sftp-server,
>> with the split between dropping binaries directly into /usr/libexec or
>> using a subdirectory apparently arbitrary.
>
> Placing openssh helpers in own subdirectory can make sense when
> there are alternative implementations.  Nevertheless, programs
> expect ${libexecdir}/sftp-server there.
>
There seems to be a specific case here with openssh and dropbear having 
alternatives for similar binaries provided by multiple packages, then we 
should handle that special case.

> Every recipe using libexecdir must be investigated whether it is placing
> only private files into it (--> candidate for ${pkglibexecdir}), or
> whether files are part of its public api (--> must be directly below
> ${libexecdir}).
>
>
>> Every package that I looked at on Debian is using
>> /usr/lib/[packagenameish]/[binary].  /usr/lib/upower/upowerd.
>> /usr/lib/telepathy/telepathy-gabble.  I say packagenameish as it's
>> often changed to be a more general name - i.e. all of the Telepathy
>> backends use /usr/lib/telepathy.
>>
>> There are no *executables*, only libraries, in /usr/lib on Debian or
>
> I do not have Debian for reference; but Ubuntu-12.04 (only a minimal,
> GUI-less installation) has
>
> /usr/lib/command-not-found
> /usr/lib/pt_chown
>
> and
>
> /usr/lib/sftp-server -> openssh/sftp-server
>
This could be done via the update-alternatives mechanism in the oe-core 
space.

>
>
>> Fedora.
>
> Fedora has /usr/libexec with lot of executables directly below it.
>
>
>> I'm really not liking dropping the executables into a directory that
>> on non-multilib is the same as libdir.
>
> When we want to follow FHS strictly, nothing prevents us from placing
> files into /usr/lib.
>
>    /usr/lib includes object files, libraries, and internal binaries
>    that are not intended to be executed directly by users or shell
>    scripts.
>
>    Applications may use a single subdirectory under /usr/lib. If an
>    application uses a subdirectory, all architecture-dependent data
>    exclusively used by the application must be placed within that
>    subdirectory.
>
>
> When we really do not want executables under ${libdir}, we can set
>
>    libexecdir = ${prefix}/lib/libexec
>
> (which might be a good setting for world-builds to detect some kind of
> libexecdir related problems).
>
I prefer what Ross suggested, fixing libexecdir to be 
${exec_prefix}/lib/${BPN}

>
>> If we want to be like the half of the world that does the same as
>> Fedora then we can revert back to /usr/libexec.  Or we can be like
>> the half of the world that does the same as Debian and use something
>> similar to ${prefix}/lib/$(DEB_SOURCE_PACKAGE) (as used in CDBS and
>> Debhelper):
>
> Debian does *not* include the package name since mid 2011
>
>          http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541458
>
I just looked at a Debian build and /usr/lib is abound with package 
directories. So given the direction we already have going with the half 
that does ${prefix}/lib/${package name} makes the most sense.  We are 
not exactly Fedora nor Debian, OE-Core is an embedded system, we are 
doing our best to match with the FHS as LSB is one of the design features.

Since I did the last libexecdir change, I will start to investigate 
changing libexecdir to be ${exec_prefix}/lib/${BPN}.  The concern I have 
with this will be plugins and other executable binaries created in a 
multilib environment.

Sau!

>
> Enrico
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>