Add method to configure preferred ABI when using RPM

[Jeff Johnson]

When using the RPM packaging backend to generate a rootfs there needs to be a way to configure the preferred ABI to resolve ELF file conflicts.

Currently RPM resolves ELF file conflicts with the last-installed wins. Using SMART it's difficult to know what the last installed will be.

[Mark-hatle (mark-hatle)]

When using the RPM packaging backend to generate a rootfs there needs to be a way to configure the preferred ABI to resolve ELF file conflicts.

Currently RPM resolves ELF file conflicts with the last-installed wins. Using SMART it's difficult to know what the last installed will be.

There are configuration settings in the RPM 'macros' file that allow you to select a specific policy for that rootfs.

There are three specific policies that can be selected:

* Last installed wins
* ELF32 wins
* ELF64 wins

A mechanism should be added to give the user the ability to select this behavior.

[Jeff Johnson (n3npq)]

This functionality is already implemented, though not used since FC3.

The values involved are carried in the transaction (lib/rpmts.c:1502)

    ts->color = rpmExpandNumeric("%{?_transaction_color}");
    ts->prefcolor = rpmExpandNumeric("%{?_prefer_color}");
    if (!ts->prefcolor) ts->prefcolor = 0x2;

Your "last installed" policy MUST take color into account
because it makes little sense to arbitrarily replace ELF32
with ELF64

[Mark-hatle (mark-hatle)]

The functionality is already in RPM5. There just is no way to control the settings from within the OE build environment.

The defect is asking for an RPM specific configuration setting to be added to OE.

[Jeff Johnson (n3npq)]

Tracked at https://bugs.launchpad.net/rpm/+bug/1172334

[Jeff Johnson (n3npq)]

OK. Note that prefcolor used for file conflict resolution
is an installation, not a build, configuration.

[Mark-hatle (mark-hatle)]

Image generation enhancement specific to RPM.

[Alexandru-c-georgescu (alexandru-c-georgescu)]

Hi,
Any updates on this? I see it still marked as 1.5.

Thanks!

[Mark-hatle (mark-hatle)]

No update, this got pushed back due to lack of time on my part to implement it.

So far nobody has complained about the wrong system behavior in these cases, I suspect due to a small population using both RPM and multilib packages.

[Liezhi-yang (liezhi-yang)]

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a9c8767a1707fa6ea40cbba99d4e12160fd91d11
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=854d9e463b9fdbd5b1d0a4000420f7f328e042f5

[Jeff Johnson (n3npq)]

I'd suggest using a different OE config name than
    RPM_PREFER_COLOR
just because of the obscurity of the functionality in RPM.

Perhaps
    RPM_PREFER_ELF_ARCH
is more informative about the specific configuration need.

See the EM_??? e_machine defines in /usr/include/elf.h
for the fundamental constants in the files that are
mapped into "color" bits that RPM uses to decide
what ELF file to install.

[Jeff Johnson (n3npq)]

Please also note that RPM color is a bit mask, not
an enumeration.

Specifically that means these bits are in use:

    0 == uncolored (i.e. a non-elf file)
    1 == 32 bit ELF
    2 == 64 bit ELF
    4 == MIPS "other endian" (and likely x32abi soon)

The comments in this patch
    http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a9c8767a1707fa6ea40cbba99d4e12160fd91d11

seem to indicate that the 0x4 bit (or enumeration value 3)
is ambiguous wrto 32 or 64 bit: I would have expected these
color bit assignments on MIPS
    1 == 32 bit mipsel (little endian)
    2 == 64 bit mipsel (little endian)
    4 == mipseb (big endian, no. of bits unspecified)
The 0x8 bit could/should be used for 64 bit mipseb if
the distinction is really important: rpm hasn't been
tested or used on a mips architecture by me this century.

The distinction is important (to rpm) when dealing with
*.a archives, which can contain multiple ELF architectures.

You can of course use an enum in OE configuration that maps
to an rpm color bit setting.

But note that setting multiple RPM color bits (like 0x3 or
0x5 or 0x7) may have some surprising behaviors.