The first pass for this will be to add warnings via the sanity test, there is a large list of recipes that have libexec, so it's not a "two minute change"!

I will work on the first part of the sanity check and then add to it to create the second part, initially these will produce WARNINGS.

Note, we should still support /usr/libexec if the user has configured the system for this.

So any sanity checks should check for the value of ${prefix}/libexec as libexecdir, and then avoid warnings/errors.

The suggested new default libexecdir format is:

${prefix}/lib/${BPN}

The default has changed in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1d18224b24a515a07170ce36dbd725cb203d3300

Unfortunately, this change breaks multilib and programs using libexecdir.  libexecdir is defined by the GNU standard as

| The definition of ‘libexecdir’ is the same for all packages

[http://www.gnu.org/prep/standards/html_node/Directory-Variables.html]

Making it dependent on architecture and ${PN} breaks programs which try to execute e.g. ${libexecdir}/sftp-server.

Blindly following FHS is a bad idea because FHS is far behind its time and does not provide solutions for problems like multilib.

One thing I bought up in the last few weeks thanks to the multilib/udev/systemd "fun" was that libexecdir should be defined like nonarch_libdir and hardcode "lib" so binaries don't move.  This doesn't entirely solve the ML problem as some libraries (ie pango, gdk-pixbuf) ship binaries in libexecdir, so they'll now conflict.

What I'm used to seeing for libdir is something like:

noarch_libdir/${bpn}

That way the things live in '/usr/lib/recipe'.  No matter what the multilib is, everything will "just work".

The only tricky bit is if two different packages want to use the same location.  A common one will need to then be defined for both.

I think the real problem is that the libexecdir wasn't used reliably in the past, so people redefined it.. it lost some of it's meaning and then with the multilibs and things like systemd/udev it's made a comeback.  But with other interesting problems.

Agreed - probably best to define a non-ML libdir name as "lib" and use it for libexecdir, nonarch_libdir, etc.  Then at least these all not munged by libdir, and we've more symbols to re-use in the recipes.

Binaries that are tied to libraries have various forms of prior art - using gdk-pixbuf as an example as a library that has a utility binary, in Debian it's in the host-specific libdir and in Fedora it gets left in bindir but suffixed with the word size.  Both of these solutions work as the binary is 99% of the time called by postinst scripts.

libexecdir should/must not contain the package name because libexecdir is like bindir and programs hardcode calls to '${libexecdir}/foreign-script'.

Well we're not the only distro to put libexecdir into /usr/lib/[package], and it hasn't been a problem.  /usr/libexec *isn't* on the path and so anything being invoked in it has to use an absolute path anyway.

Which other distributions are making libexecdir dependent on ${PN}?

Debian and Ubuntu are obvious examples:

$ ls /usr/libexec
ls: cannot access /usr/libexec: No such file or directory

Debian defines libexecdir to be /usr/lib (minus multilib issues).

I speak about ${PN} in libexecdir; e.g. libexecdir would be

   /usr/lib/openssh-server   for openssh.bb
   /usr/lib/dropbear for dropbear.bb

dropbear calls '${libexecdir}/sftp-server' which is valid for openssh but not for dropbear.

> I speak about ${PN} in libexecdir; e.g. libexecdir would be

BPN vs PN, since the PN can have the multilib in the name...

>   /usr/lib/openssh-server   for openssh.bb
>   /usr/lib/dropbear for dropbear.bb
>
> dropbear calls '${libexecdir}/sftp-server' which is valid for openssh but not for dropbear.

This is a place where coordination between packages is required.  In this case I'd expect openssh to set the standard and dropbear to either define it's own or use the definition from openssh.

I think the key thing is to define a reasonable value for the libexecdir, and then make sure recipes can override it easily as necessary.

> BPN vs PN, since the PN can have the multilib in the name...

ok; there is a difference between BPN and PN. But with both, libexecdir would be inconsistent between packages violating expectations raised by the GNU standard.


> This is a place where coordination between packages is required.  In this case
> I'd expect openssh to set the standard and dropbear to either define it's own
> or use the definition from openssh.

How would you refer to /usr/lib/openssh/sftp-server from within dropbear by using '${libexecdir}'?  Define a global SFTP_SERVER_PATH variable in bitbake.conf?

> How would you refer to /usr/lib/openssh/sftp-server from within dropbear by using '${libexecdir}'?  Define a global SFTP_SERVER_PATH variable in bitbake.conf?

Following that few conversations, I'd have to say:

${nonarch_libdir}/openssh/sftp-server

The coordination is that both the openssh(-sftp) package and dropbear need to agree that the subdirectory 'openssh' is correct.  The nonarch_libdir would be /lib or /usr/lib depending on settings.

(Note, I don't see a nonarch_libdir defined, but I do see "nonarch_base_libdir" defined currently.  So this strategy may require enhancements.)

My suggestion would be:

export nonarch_base_libdir = "${base_prefix}/lib"
export nonarch_libdir = "${exec_prefix}/lib"
export libexecdir = "${nonarch_libdir}/${BPN}"

For things like systemd/udev who need the libexecdir to be in the root, they should be able to define:

libexecdir = "${nonarch_base_libdir}/${BPN}"

for things like the sftp above, both recipes could define:

libexecdir = "${nonarch_libdir}/openssh"

(or even)

libexecdir = "${nonarch_libdir}/sftp"

I disagree with the libexecdir definition.

| export libexecdir = "${nonarch_libdir}"

would be much better and matches nearly all other linux distributions (minus multilib and 'libexec' vs. 'lib' issues).

libexecdir must expand to the same value for every package.

Usually, packages place files into ${libexecdir}/@PACKAGE@  (aka the non-standard 'pkglibexecdir').  For packages like openssh, an explicit

| EXTRA_OECONF += "--libexecdir=${libexecdir}/openssh"

should be added so that files are not installed directly below /usr/lib

In my experience there isn't a "usually" for packages installing into $libexecdir/[binary] or $libexecdir/[package]/[binary], both are commonplace.