Re: libexecdir and multilib

[Mark Hatle <mark.hatle@windriver.com>]

On 5/2/13 11:10 AM, Burton, Ross wrote:
> Hi all,
>
> There were several issues being discussed here under the topic of
> libexecdir, some simple and some less so.  I'll ramble for a bit to
> try and get a proper conclusion debated.
>
> The situation where you have a 32-bit dropbear but a 64-bit openssh is
> rather pathological and I'd like to know if this was a real-world
> problem and the rationale behind it, or whether it was an example of a
> hypothetical issue.  Note that the example of Debian using "/usr/lib"
> as libexecdir is true only in the case where ML isn't being used, then
> libexecdir is $prefix/lib/$arch, which will have the same hypothetical
> problem.  Debian's SSH works because dropboard and openssh aren't
> multilib-enabled - if you look at e.g. libgstreamer in Debian you'll
> see the libexecdir there is arch-qualified.
>
> Looking at the latest FHS drafts and the revised automake
> documentation, I agree that our default --libexecdir shouldn't contain
> ${BPN}.  There may be packages that drop unrealistic numbers of
> binaries into libexecdir and for those we can join most other
> distributions and change libexecdir on a per-package basis.  However
> the exact choice of libexecdir depends on what ML behaviour we expect
> and have from the package managers, which predictably isn't uniform.
>
> If it wasn't for multilib, this wouldn't be a issue - we could just
> change the libexecdir definition to whatever we wanted.  However,
> multilib does exist and causes all sorts of annoyances, mainly around
> conflicting binaries.  As far as I'm aware rpm and opkg have different
> behaviour when binaries conflict in packages: rpm allows "executables"
> (but not libraries) to conflict and will prefer the 64-bit version,

Minor clarification.  RPM permits ELF executables to "conflict" and resolves 
them using a local policy.  The default local policy happens to be 64-bit right 
now.  (We've got an open defect to permit this policy to change.)

> whereas opkg allows files in $bindir (etc) to conflict.  So, rpm can
> handle an arbitrary libexecdir but opkg can't at present.
>
> So there are three options that I can see:
>
> libexecdir = "$libdir"
> ===
>
> No conflicting binaries in libexecdir when multilib is used, so
> companion binaries used by libraries don't get used by different
> architectures.  Other packages accessing the libexecdir could have
> different architecture, but this is likely a rare situation.

Do we have any cases where a library will care about the byte size of the 
libexecdir executable?  I'm not aware of any....

> libexecdir = "${exec_prefix}/lib"
> ===
>
> 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.  There is the
> possibility of a /usr/lib solely containing libexecdir binaries if the
> ML configuration means that the libdirs used are lib32 and lib64,
> which would look odd.
>
> 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.
>
> 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.
>
> gdk-pixbuf has a tool to introspect/register the installed loader
> modules.  As this loads the libraries, it needs to match the
> architecture of the libgdk-pixbuf being used.  Upstream has this tool
> installing to $bindir yet multilib distributions can't have this tool
> being replaced with different architectures, so Fedora adds a
> word-size suffix to the binary, and Debian moves it to their
> libexecdir (which in ML-compatible packages in $libdir/$arch), and
> both adapt their postinst scripts to match.
>
> Both of these examples are in mainstream packages where the package
> maintainers in the distro are also upstream developers, and yet these
> kludges exist (note that our gdk-pixbuf is currently broken in this
> respect).
>
> My personal opinion at this point in time is that we should change
> libexecdir to be $libdir.  My rationale for this is these internal
> binaries then "stick" with their architecture, and that the number of
> binaries that need to be invoked and match their library's
> architecture is likely higher than the number of cross-package and
> cross-architecture hard-coded execution paths (such as 32-bit dropbear
> running 64-bit openssh helpers).

I'm looking for examples of a libexecdir that -is- architecture specific.  I.e. 
a library (or something external) calls it and expects a specific byte size 
version.  If this is the case (gstreamer, dbus, etc?) then $libdir does make 
sense with the update-alternative link being in ${exec_prefix}/lib/... so that 
shell scripts and other things can find it..

--Mark

> Hopefully nobody got too bored reading this, any comments?
>
> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>