[PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

[PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

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

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

-- 
1.7.10.4

[PATCH 1/4] eglibc: WIP fix paths for libexec

[Ross Burton]

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-core/glibc/glibc-package.inc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc
index 6212e5b..7a89db8 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -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.*"
-- 
1.7.10.4

[PATCH 2/4] neard: remove libexec hacks

[Ross Burton]

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 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(-)

diff --git a/meta/recipes-connectivity/neard/neard.inc b/meta/recipes-connectivity/neard/neard.inc
index e714cad..59ae9b0 100644
--- a/meta/recipes-connectivity/neard/neard.inc
+++ b/meta/recipes-connectivity/neard/neard.inc
@@ -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"
 
diff --git a/meta/recipes-connectivity/neard/neard/neard.in b/meta/recipes-connectivity/neard/neard/neard.in
index a47d4d9..c9e72ae 100644
--- a/meta/recipes-connectivity/neard/neard/neard.in
+++ b/meta/recipes-connectivity/neard/neard/neard.in
@@ -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"
 
diff --git a/meta/recipes-connectivity/neard/neard/neard.service.in b/meta/recipes-connectivity/neard/neard/neard.service.in
index a6f8a84..458173f 100644
--- a/meta/recipes-connectivity/neard/neard/neard.service.in
+++ b/meta/recipes-connectivity/neard/neard/neard.service.in
@@ -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
-- 
1.7.10.4

[PATCH 3/4] weston: fix plugin location in FILES

[Ross Burton]

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

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-graphics/wayland/weston_1.6.0.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston_1.6.0.bb b/meta/recipes-graphics/wayland/weston_1.6.0.bb
index efbbbe0..d30e48b 100644
--- a/meta/recipes-graphics/wayland/weston_1.6.0.bb
+++ b/meta/recipes-graphics/wayland/weston_1.6.0.bb
@@ -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"
-- 
1.7.10.4

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

[Ross Burton]

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/conf/bitbake.conf |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0ccaac0..a3a8988 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -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"
-- 
1.7.10.4

Re: [PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

[Mark Hatle]

On 12/2/14, 9:53 AM, Ross Burton wrote:
> 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.

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

Re: [PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On 2 December 2014 at 17:02, Mark Hatle <mark.hatle@windriver.com> 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.)
>

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


> 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

[-- Attachment #2: Type: text/html, Size: 1544 bytes --]

Re: [PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

[Mark Hatle]

On 12/2/14, 11:10 AM, Burton, Ross wrote:
>
> On 2 December 2014 at 17:02, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@windriver.com>> 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.)
>
>
> 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?)

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


> Ross

Re: [PATCH 0/4][RFC] Change libexecdir to ${prefix}/libexec

[Koen Kooi]

> Op 2 dec. 2014, om 16:53 heeft Ross Burton <ross.burton@intel.com> 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.
> 
> 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