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.
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
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.
Tracked at https://bugs.launchpad.net/rpm/+bug/1172334
OK. Note that prefcolor used for file conflict resolution is an installation, not a build, configuration.
Image generation enhancement specific to RPM.
Hi, Any updates on this? I see it still marked as 1.5. Thanks!
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.
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
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.
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.