[OE-core] libexecdir and multilib

[Mark Hatle]

On 5/2/13 12:24 PM, Enrico Scholz wrote:
> "Burton, Ross" <ross.burton at 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.

RPM rule (doesn't matter rpm4 or rpm5), they have the same multilib rules.

If the file color (type) is -not- ELF, then a conflict occurs if the files are 
different.

If the file color (type) is ELF, then the policy is used to decide if this is a 
conflict, or which version wins.

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

Just because we're using RPM doesn't mean we have to follow Fedora.  There are a 
lot of things that Fedora does wrong (and right) IMHO.  Same with Debian and 
others.  We need to make sure we do appropriate choices based on the users of 
OE-Core.  These users may need specific situations and/or expect certain 
configurations that they are used to from Fedora.  So deviating for the sake of 
deviating is bad as well... There needs to be a technical reason for it.

>
>> 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>