Skip to contentSkip to conversation

Change libexecdir to ${prefix}/libexec

RFC PATCH In review Ross Burton 3 participants 9 messages Dec 2, 2014 – Dec 3, 2014

lore
Share & tools
lore
#0 lore raw

cover Change libexecdir to ${prefix}/libexec

Hi,

First, this is VERY MUCH A RFC!

There's numerous problems with setting ${libexecdir} to ${libdir}/${BPN}, but the a easy argument in my opinion is that nobody else does this.

The Debian world sets libexecdir to ${exec_prefix}/lib, and the Red Hat world uses ${exec_prefix}/libexec. The FHS says either are fine. Nobody puts the package name into the definition of libexecdir, as automake provides pkglibexecdir ($libexec/$package) for package-specific binaries.

This branch changes bitbake.conf to use ${exec_prefix}/libexec and a few patches to fix (or hack around) any problems this has revealed so far.

Comments and testing (especially with other layers, and multilib configurations) much appreciated.

Ross

The following changes since commit b8631416f12b8a904ce3deb036f9d5ce632937b0:

package_regex.inc: Update REGEX'es in order to find upstream versions correctly (2014-11-28 14:03:02 +0000)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ross/libexec

for you to fetch changes up to ed5b853fc4626afabcad8171f478893d5fb438f5:

bitbake: set libexecdir to prefix/libexec (2014-12-02 15:43:36 +0000)

----------------------------------------------------------------
Ross Burton (4):
eglibc: WIP fix paths for libexec
neard: remove libexec hacks
weston: fix plugin location in FILES
bitbake: set libexecdir to prefix/libexec

 meta/conf/bitbake.conf                                 |    4 ++--
 meta/recipes-connectivity/neard/neard.inc              |   10 +++-------
 meta/recipes-connectivity/neard/neard/neard.in         |    2 +-
 meta/recipes-connectivity/neard/neard/neard.service.in |    2 +-
 meta/recipes-core/glibc/glibc-package.inc              |    2 +-
 meta/recipes-graphics/wayland/weston_1.6.0.bb          |    2 +-
 6 files changed, 9 insertions(+), 13 deletions(-)

Ross Burton (4):
eglibc: WIP fix paths for libexec
neard: remove libexec hacks
weston: fix plugin location in FILES
bitbake: set libexecdir to prefix/libexec

 meta/conf/bitbake.conf                                 |    4 ++--
 meta/recipes-connectivity/neard/neard.inc              |   10 +++-------
 meta/recipes-connectivity/neard/neard/neard.in         |    2 +-
 meta/recipes-connectivity/neard/neard/neard.service.in |    2 +-
 meta/recipes-core/glibc/glibc-package.inc              |    2 +-
 meta/recipes-graphics/wayland/weston_1.6.0.bb          |    2 +-
 6 files changed, 9 insertions(+), 13 deletions(-)
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/4 eglibc: WIP fix paths for libexec

---
 meta/recipes-core/glibc/glibc-package.inc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-core/glibc/glibc-package.inc +1 -1
index 6212e5b..7a89db8 100644
@@ -33,7 +33,7 @@ RPROVIDES_${PN}-pcprofile = "eglibc-pcprofile"
 RPROVIDES_${PN}-dbg = "eglibc-dbg"
 libc_baselibs = "${base_libdir}/libcrypt*.so.* ${base_libdir}/libcrypt-*.so ${base_libdir}/libc.so.* ${base_libdir}/libc-*.so ${base_libdir}/libm*.so.* ${base_libdir}/libm-*.so ${base_libdir}/ld*.so.* ${base_libdir}/ld-*.so ${base_libdir}/libpthread*.so.* ${base_libdir}/libpthread-*.so ${base_libdir}/libresolv*.so.* ${base_libdir}/libresolv-*.so ${base_libdir}/librt*.so.* ${base_libdir}/librt-*.so ${base_libdir}/libutil*.so.* ${base_libdir}/libutil-*.so ${base_libdir}/libnsl*.so.* ${base_libdir}/libnsl-*.so ${base_libdir}/libnss_files*.so.* ${base_libdir}/libnss_files-*.so ${base_libdir}/libnss_compat*.so.* ${base_libdir}/libnss_compat-*.so ${base_libdir}/libnss_dns*.so.* ${base_libdir}/libnss_dns-*.so ${base_libdir}/libdl*.so.* ${base_libdir}/libdl-*.so ${base_libdir}/libanl*.so.* ${base_libdir}/libanl-*.so ${base_libdir}/libBrokenLocale*.so.* ${base_libdir}/libBrokenLocale-*.so"
 
-FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf', '', d)}"
+FILES_${PN} = "${libc_baselibs} ${libexecdir} ${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig ${sysconfdir}/ld.so.conf', '', d)}"
 FILES_ldd = "${bindir}/ldd"
 FILES_libsegfault = "${base_libdir}/libSegFault*"
 FILES_libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
Signature · 1 line
1.7.10.4
#2 lore raw

PATCH 2/4 neard: remove libexec hacks

In reply to Ross Burton
---
 meta/recipes-connectivity/neard/neard.inc              |   10 +++-------
 meta/recipes-connectivity/neard/neard/neard.in         |    2 +-
 meta/recipes-connectivity/neard/neard/neard.service.in |    2 +-
 3 files changed, 5 insertions(+), 9 deletions(-)
meta/recipes-connectivity/neard/neard.inc +3 -7
index e714cad..59ae9b0 100644
@@ -13,22 +13,18 @@ inherit autotools-brokensep pkgconfig systemd update-rc.d
 
 EXTRA_OECONF += "--enable-tools"
 
-do_install() {
-	oe_runmake DESTDIR=${D} libexecdir=${libexecdir} install
-}
-
 # This would copy neard start-stop shell and test scripts
 do_install_append() {
 	if ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'true', 'false', d)}; then
 		install -d ${D}${sysconfdir}/init.d/
-		sed "s:@installpath@:${libexecdir}:" ${WORKDIR}/neard.in \
+		sed "s:@pkglibexecdir@:${libexecdir}/nfc:" ${WORKDIR}/neard.in \
 		  > ${D}${sysconfdir}/init.d/neard
 		chmod 0755 ${D}${sysconfdir}/init.d/neard
 	fi
 
 	if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
 		install -d ${D}${systemd_unitdir}/system
-		sed "s:@installpath@:${libexecdir}:" ${WORKDIR}/neard.service.in \
+		sed "s:@pkglibexecdir@:${libexecdir}/nfc:" ${WORKDIR}/neard.service.in \
 		  > ${D}${systemd_unitdir}/system/neard.service
 	fi
 
@@ -41,7 +37,7 @@ do_install_append() {
 PACKAGES =+ "${PN}-tests"
 
 FILES_${PN}-tests = "${libdir}/${BPN}/*-test"
-FILES_${PN}-dbg += "${libdir}/${BPN}/*/.debug"
+FILES_${PN}-dbg += "${libexecdir}/nfc/.debug ${libdir}/${BPN}/*/.debug"
 
 RDEPENDS_${PN} = "dbus python python-dbus python-pygobject"
 
meta/recipes-connectivity/neard/neard/neard.in +1 -1
index a47d4d9..c9e72ae 100644
@@ -12,7 +12,7 @@
 # Description:       neard is a daemon used to enable NFC features
 ### END INIT INFO
 
-DAEMON=@installpath@/neard
+DAEMON=@pkglibexecdir@/neard
 PIDFILE=/var/run/neard.pid
 DESC="Linux NFC daemon"
 
meta/recipes-connectivity/neard/neard/neard.service.in +1 -1
index a6f8a84..458173f 100644
@@ -6,7 +6,7 @@ After=syslog.target
 [Service]
 Type=dbus
 BusName=org.neard
-ExecStart=@installpath@/neard -n
+ExecStart=@pkglibexecdir@/neard -n
 
 [Install]
 Alias=dbus-org.neard.service
Signature · 1 line
1.7.10.4
#3 lore raw

PATCH 3/4 weston: fix plugin location in FILES

In reply to Ross Burton

The plugins are installed to ${libdir}/weston, not ${libexecdir}.

---
 meta/recipes-graphics/wayland/weston_1.6.0.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-graphics/wayland/weston_1.6.0.bb +1 -1
index efbbbe0..d30e48b 100644
@@ -79,7 +79,7 @@ do_install_append() {
 
 PACKAGES += "${PN}-examples"
 
-FILES_${PN} = "${bindir}/weston ${bindir}/weston-terminal ${bindir}/weston-info ${bindir}/weston-launch ${bindir}/wcap-decode ${libexecdir} ${datadir}"
+FILES_${PN} = "${bindir}/weston ${bindir}/weston-terminal ${bindir}/weston-info ${bindir}/weston-launch ${bindir}/wcap-decode ${libdir}/weston ${datadir}"
 FILES_${PN}-examples = "${bindir}/*"
 
 RDEPENDS_${PN} += "xkeyboard-config"
Signature · 1 line
1.7.10.4
#4 lore raw

PATCH 4/4 bitbake: set libexecdir to prefix/libexec

In reply to Ross Burton
---
 meta/conf/bitbake.conf |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +2 -2
index 0ccaac0..a3a8988 100644
@@ -38,7 +38,7 @@ export systemd_unitdir = "/lib/systemd"
 export bindir = "${exec_prefix}/bin"
 export sbindir = "${exec_prefix}/sbin"
 export libdir = "${exec_prefix}/${baselib}"
-export libexecdir = "${libdir}/${BPN}"
+export libexecdir = "${exec_prefix}/libexec"
 export includedir = "${exec_prefix}/include"
 export oldincludedir = "${exec_prefix}/include"
 localedir = "${libdir}/locale"
@@ -52,7 +52,7 @@ bindir_native = "${prefix_native}/bin"
 sbindir_native = "${prefix_native}/sbin"
 includedir_native = "${prefix_native}/include"
 libdir_native = "${prefix_native}/lib"
-libexecdir_native = "${libdir_native}/${BPN}"
+libexecdir_native = "${prefix_native}/libexec"
 base_libdir_native = "/lib"
 datadir_native = "${prefix_native}/share"
 bindir_cross = "/bin"
Signature · 1 line
1.7.10.4
#5 lore raw
In reply to Ross Burton
Quoted 11 lines · Ross Burton

Hi,

First, this is VERY MUCH A RFC!

There's numerous problems with setting ${libexecdir} to ${libdir}/${BPN}, but the a easy argument in my opinion is that nobody else does this.

The Debian world sets libexecdir to ${exec_prefix}/lib, and the Red Hat world uses ${exec_prefix}/libexec. The FHS says either are fine. Nobody puts the package name into the definition of libexecdir, as automake provides pkglibexecdir ($libexec/$package) for package-specific binaries.

Originally this was choosen because most packages were -not- using pkglibexecdir. This was causing a libexecdir that was containing multiple, sometimes conflicting binary names.

So the fix was either patch the recipes to add their BPN, or just add the BPN to the libexecdir itself.

Personally I think using "${exec_prefix}/libexec" is incorrect. This does not support a multilib configuration where you may have both a 64-bit and 32-bit version of the libexec program on the system. (perhaps this isn't a real problem, but we ran into some conflicts in the past.)

So moving to the libdir, ensures that we are unique per multilib.. and the BPN ensures that we're unique per recipe.

Quoted 49 lines

This branch changes bitbake.conf to use ${exec_prefix}/libexec and a few patches to fix (or hack around) any problems this has revealed so far.

Comments and testing (especially with other layers, and multilib configurations) much appreciated.

Ross

The following changes since commit b8631416f12b8a904ce3deb036f9d5ce632937b0:

package_regex.inc: Update REGEX'es in order to find upstream versions correctly (2014-11-28 14:03:02 +0000)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ross/libexec

for you to fetch changes up to ed5b853fc4626afabcad8171f478893d5fb438f5:

   bitbake: set libexecdir to prefix/libexec (2014-12-02 15:43:36 +0000)

----------------------------------------------------------------
Ross Burton (4):
eglibc: WIP fix paths for libexec
neard: remove libexec hacks
weston: fix plugin location in FILES
bitbake: set libexecdir to prefix/libexec

  meta/conf/bitbake.conf                                 |    4 ++--
  meta/recipes-connectivity/neard/neard.inc              |   10 +++-------
  meta/recipes-connectivity/neard/neard/neard.in         |    2 +-
  meta/recipes-connectivity/neard/neard/neard.service.in |    2 +-
  meta/recipes-core/glibc/glibc-package.inc              |    2 +-
  meta/recipes-graphics/wayland/weston_1.6.0.bb          |    2 +-
  6 files changed, 9 insertions(+), 13 deletions(-)

Ross Burton (4):
eglibc: WIP fix paths for libexec
neard: remove libexec hacks
weston: fix plugin location in FILES
bitbake: set libexecdir to prefix/libexec

  meta/conf/bitbake.conf                                 |    4 ++--
  meta/recipes-connectivity/neard/neard.inc              |   10 +++-------
  meta/recipes-connectivity/neard/neard/neard.in         |    2 +-
  meta/recipes-connectivity/neard/neard/neard.service.in |    2 +-
  meta/recipes-core/glibc/glibc-package.inc              |    2 +-
  meta/recipes-graphics/wayland/weston_1.6.0.bb          |    2 +-
  6 files changed, 9 insertions(+), 13 deletions(-)
#6 lore raw
Quoted 5 lines · Mark Hatle

Personally I think using "${exec_prefix}/libexec" is incorrect. This does not support a multilib configuration where you may have both a 64-bit and 32-bit version of the libexec program on the system. (perhaps this isn't a real problem, but we ran into some conflicts in the past.)

Are any of these conflicts actually a problem? Can you give an example? I know there's been several attempts to "fix" GConf multilib installation which were generally breaking GConf instead of fixing a test case...

Quoted 3 lines

So moving to the libdir, ensures that we are unique per multilib.. and the BPN ensures that we're unique per recipe.

A libexecdir that isn't global is a problem because some packages want to run *other recipes* binaries, and they can't just do $libexecdir/some-binary.

Ross

#7 lore raw
Quoted 10 lines · Ross

On 2 December 2014 at 17:02, Mark Hatle <[email protected] <mailto:[email protected]>> wrote:

Personally I think using "${exec_prefix}/libexec" is incorrect. This does not support a multilib configuration where you may have both a 64-bit and 32-bit version of the libexec program on the system. (perhaps this isn't a real problem, but we ran into some conflicts in the past.)

Quoted 3 lines

Are any of these conflicts actually a problem? Can you give an example? I know there's been several attempts to "fix" GConf multilib installation which were generally breaking GConf instead of fixing a test case...

I simply don't remember anymore. It was an issue were a 32-bit and 64-bit version of whatever it was, wasn't working properly. It was returning values that were specific to the libdir.

The problem was discovered in comprehensive system testing... but for the life of me I can't remember what the problem was. (and for all I know it's not a problem anymore?)

Quoted 6 lines

So moving to the libdir, ensures that we are unique per multilib.. and the BPN ensures that we're unique per recipe.

A libexecdir that isn't global is a problem because some packages want to run *other recipes* binaries, and they can't just do $libexecdir/some-binary.

The other binary problem was addressed by either changing the libexec path for the provider, or setting to libdir/${BPN} for the user.

Quoted 1 line

Ross

#8 lore raw
In reply to Ross Burton
Quoted 15 lines

Op 2 dec. 2014, om 16:53 heeft Ross Burton <[email protected]> het volgende geschreven:

Hi,

First, this is VERY MUCH A RFC!

There's numerous problems with setting ${libexecdir} to ${libdir}/${BPN}, but the a easy argument in my opinion is that nobody else does this.

The Debian world sets libexecdir to ${exec_prefix}/lib, and the Red Hat world uses ${exec_prefix}/libexec. The FHS says either are fine. Nobody puts the package name into the definition of libexecdir, as automake provides pkglibexecdir ($libexec/$package) for package-specific binaries.

Quoted 5 lines

This branch changes bitbake.conf to use ${exec_prefix}/libexec and a few patches to fix (or hack around) any problems this has revealed so far.

Comments and testing (especially with other layers, and multilib configurations) much appreciated.

In the past I've patched things like gdm to look in ${libdir}/${BPN} for helper binaries (which are from a different recipe), so not only recipes need to be inspected, but patches as well.

regards,

Koen