[OE-core] [PATCH 38/44] package_rpm.bbclass: do not strip multilib prefixes from package names, do not add multilib prefix to package arch

Alexander Kanavin alexander.kanavin at linux.intel.com
Mon Mar 13 14:35:43 UTC 2017


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



More information about the Openembedded-core mailing list