| Summary: | Add method to configure preferred ABI when using RPM | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mark Hatle <mark.hatle> |
| Component: | core | Assignee: | Robert Yang <liezhi.yang> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | alexandru.c.georgescu, liezhi.yang, meta.mr.watcher, meta.watcher, n3npq |
| Version: | unspecified | ||
| Target Milestone: | 1.7 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | IMAGEGEN | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
| Bug Depends on: | |||
| Bug Blocks: | 4106, 4685 | ||
|
Description
Mark Hatle
2013-03-21 14:58:38 UTC
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.
|