Re: libexecdir and multilib

[Enrico Scholz <enrico.scholz@sigma-chemnitz.de>]

"Burton, Ross" <ross.burton@intel.com> writes:

> rpm allows "executables" (but not libraries) to conflict and will
> prefer the 64-bit version,

Sure? At least rpm-4 (Fedora, RHEL) does not allow files to conflict.
Fedora solves the multilib problem by splitting the distribution into
main packages (unilib only; contain binaries and data) and libraries
(multilib).  The distribution assemble tool ("mash") copies e.g. i386
-lib and -devel packages both in i386 and x86_64 repositories.

libexecdir files in Fedora should be part of unilib (main architecture)
packages only.


> libexecdir = ${exec_prefix}/libexec"
> ===
>
> Conflicting binaries with multilib, would likely need improvements in
> the opkg bbclass.  Consistent name so cross-architecture file paths
> are consistent, although the binary architecture isn't.

How is ${bindir} multilib packaging solved in OE?  Can this mechanism
applied to ${exec_prefix}/libexec too?


> What's clear from the research I've done is that there isn't a clear
> answer - upstreams have different expectations of how libexecdir/bindir
> are used, and different distributions do different things to solve the
> multilib problems - even when the distribution maintainers are also
> upstream developers.  Some examples:
>
> dbus has a helper dbus-daemon-launch-helper, which is installed into
> libexecdir.  Fedora moves it into $libdir, where as Debian moves this
> same binary to /usr/lib/dbus-1 avoiding the $arch... Some disagreement
> there apparently.

Yes; Fedora introduced this in 2007[1] without telling the rationale in
the commit :( afais, this is not give problems because path is read from
<serviceconfig> tag in /etc/dbus-1/system.conf and program is probably
called only from dbus library itself.


> My personal opinion at this point in time is that we should change
> libexecdir to be $libdir.

atm, multilib is a theoretical issue for me only and I do not have a
strong bias for ${libdir} vs. ${exec_prefix}/lib.

Nevertheless, when we change libexecdir to match ${libdir} in one
architecture, we will see packaging regressions.  To fix/detect them,
we will have to:

1. remove ${libexecdir}/* wildcards from FILES lists (permanent change)

2. do world builds with "strange", temporary libexecdir
   (e.g. /usr/lib/strange-libexec) and look for unpackaged files.



Enrico

Footnotes: 
[1]  http://pkgs.fedoraproject.org/cgit/dbus.git/commit/?id=73fe28f678b4a1f015bffbec0fa50b3690dd39a4