On 5/2/13 12:24 PM, Enrico Scholz wrote:
"Burton, Ross" <[email protected]> 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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
