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