On 03/10/2017 07:04 PM, Mark Hatle wrote:
On 3/10/17 5:24 AM, Alexander Kanavin wrote:
This is done for reasons I cannot establish, and greatly complicates the code
that installs packages into rootfs.
RPM internally resolves ELF dependencies through a resolution system.
If you look at a typical Fedora, SuSe, etc system you will often see:
glibc-x.y.i386.rpm
glibc-x.y.x86-64.rpm
When a package asks for 'glibc', the system will go out and match the one for
the arch that is being requested.
I don't know the core reason for it, but it actually does not happen,
and I saw it firsthand. When a package needs a library, the resolver
will pick the library package with the architecture that has the higher
priority in the list of architectures, not the architecture that would
match the package correctly.
When using smart, there seems to be a similar issue:
# Pull in multilib requires since rpm may not pull in them
# correctly, for example,
# lib32-packagegroup-core-standalone-sdk-target requires
# lib32-libc6, but rpm may pull in libc6 rather than lib32-libc6
# since it doesn't know mlprefix (lib32-), bitbake knows it and
# can handle it well, find out the RDEPENDS on the chain will
# fix the problem. Both do_rootfs and do_populate_sdk have this
# issue.
# The attempt_only packages don't need this since they are
# based on the installed ones.
#
# Separate pkgs into two lists, one is multilib, the other one
# is non-multilib.
... which is then followed by the most hackish, impementrable code that
recursively walks RDEPENDS and massages that into a list that is given
to smart, effectively subverting smart's own dependency resolution. I do
not want to carry this into rpm4/dnf (or even spend time understanding
it), and so I dropped both the multilib prefix stripping, and the code
that works around it.
By the way, I don't know about Fedora, but SuSE does use -32bit suffixes
in package names.
Alex
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
