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

Enrico Scholz enrico.scholz at sigma-chemnitz.de
Mon Apr 29 17:03:43 UTC 2013


"Burton, Ross" <ross.burton-ral2JQCrhuEAvxtiuMwx3w at 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.


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

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



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


> 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


Enrico




More information about the Openembedded-core mailing list