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

[Enrico Scholz]

Saul Wold <sgw at linux.intel.com> 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.

Yes; automake calls this

  pkglibexecdir = $(libexecdir)/@PACKAGE@

and lot of packages are using it already to install their files.


>   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).

Yes; but this is thing of the package, not of the distribution.  When a
distribution thinks, a package pollutes $(libexecdir), the distribution
can fix *this* package.  But $(libexecdir) provided by the distribution
must never contain the package name.


>> 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}

$(libexecdir) has the same meaning like $(bindir); so why do we not have

  bindir = $(prefix)/bin/${BPN}

?

Again: $(libexecdir) must be the same for every package.  All major
linux distributions follow this; why should oe differ from this rule?


>>> 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.

Nobody forbids this and it is completely fine and suggested that
packages install their files below $(pkglibexecdir).  But Debian
defines libexecdir as /usr/lib (plus an optional multiarch tag from
DEB_HOST_MULTIARCH (whatever this is)).


> Since I did the last libexecdir change, I will start to investigate
> changing libexecdir to be ${exec_prefix}/lib/${BPN}.

This is a no-go because it breaks the GNU standard like the recent
value.  fwiw, my preferences for libexecdir are (in this order):

1. ${prefix}/libexec

   --> clean separation, commonly used, but not FHS compliant (unless
   somebody interprets "/usr/lib<qual> : Alternate format libraries
   (optional)" with '<qual>=exec')

2. ${prefix}/lib

   --> follows the Debian way and is 100% FHS compliant, but might
   pollute ${libdir} and might introduce regressions in oe packaging

3. ${prefix}/lib/libexec

   --> clean separation, probably FHS compliant, but smells hacky


> The concern I have with this will be plugins and other executable
> binaries created in a multilib environment.

Plugins (aka "libraries to be loaded") are not interesting (they do not
belong into ${libexecdir}).  Executables within ${libexecdir} are to be
handled like these in ${bindir}, so that a proper libexecdir won't cause
any new multilib issue.



Enrico