2915 2012-08-08 04:40:07 +0000 Don't use /usr/libexec 2013-04-26 18:30:53 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED (patch review) Medium normal 1.4 1 ross.burton sgw enrico.scholz mark.hatle meta.mr.watcher meta.watcher richard.purdie --- --- --- oldest_to_newest 23875 0 ross.burton 2012-08-08 04:40:07 +0000 The FHS doesn't mention /usr/libexec and we should aim to be as FHS-compliant as possible. Distros without libexec normally use /usr/lib/[source package name]/ instead. This should be a two minute change to make, but verifying will be harder. A sanity check that nothing was installed into /usr/libexec will be a start, but can we grep the installed scripts/binaries to verify that nothing has hardcoded /usr/libexec into an executable? 23961 1 sgw 2012-08-13 14:04:58 +0000 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. 23974 2 mark.hatle 2012-08-13 17:13:01 +0000 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} 26709 3 richard.purdie 2012-10-18 11:46:41 +0000 The default has changed in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1d18224b24a515a07170ce36dbd725cb203d3300 32674 4 enrico.scholz 2013-04-26 15:24:54 +0000 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. 32675 5 ross.burton 2013-04-26 15:31:38 +0000 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. 32676 6 mark.hatle 2013-04-26 15:39:40 +0000 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. 32677 7 ross.burton 2013-04-26 15:45:08 +0000 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. 32678 8 enrico.scholz 2013-04-26 15:46:13 +0000 libexecdir should/must not contain the package name because libexecdir is like bindir and programs hardcode calls to '${libexecdir}/foreign-script'. 32679 9 ross.burton 2013-04-26 15:55:57 +0000 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. 32680 10 enrico.scholz 2013-04-26 16:09:02 +0000 Which other distributions are making libexecdir dependent on ${PN}? 32681 11 ross.burton 2013-04-26 16:11:24 +0000 Debian and Ubuntu are obvious examples: $ ls /usr/libexec ls: cannot access /usr/libexec: No such file or directory 32682 12 enrico.scholz 2013-04-26 16:14:21 +0000 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. 32684 13 mark.hatle 2013-04-26 16:33:15 +0000 > 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. 32685 14 enrico.scholz 2013-04-26 16:43:25 +0000 > 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? 32686 15 mark.hatle 2013-04-26 17:00:06 +0000 > 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" 32687 16 enrico.scholz 2013-04-26 17:07:10 +0000 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 32688 17 ross.burton 2013-04-26 18:30:53 +0000 In my experience there isn't a "usually" for packages installing into $libexecdir/[binary] or $libexecdir/[package]/[binary], both are commonplace.