"Burton, Ross" <ross.bur...@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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
