Bug 412811 - /etc/rpm/macros _transaction_color inconsistency
/etc/rpm/macros _transaction_color inconsistency
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-05 15:36 EST by Philippe Troin
Modified: 2008-06-03 14:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-03 14:35:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Philippe Troin 2007-12-05 15:36:11 EST
Description of problem:
Two slightly different x86_64 systems.
After the default install one has a /etc/rpm/macros file containing:
  %_transaction_color   3
The other does not.

What is the _transaction_color, and why would it differ between two mostly
similar machines?

Version-Release number of selected component (if applicable):

How reproducible:
I don't know.

Comment 1 Jeff Johnson 2007-12-06 08:35:36 EST
Transaction color is a bit mask with 2 bits that determines
how dependencies between ELF32 and ELF64 executables
and libraries are to be resolved.
    1 == ELF32
    2 == ELF64

The value should likely be "3" everywhere these days.

Why the value differs has to do with how the machines were configured.
All versions of rpm since RHL9 (and rpm-4.2.2) have used "3" as the default
value for transaction_color for 3+ years.
Comment 2 Panu Matilainen 2007-12-07 14:45:44 EST
Anaconda writes it in .. some cases as a workaround to an ancient bug.

The difference between those two "mostly similar" systems is that other one is
an Intel and the other one is AMD and the output from this differs:
$ python -c "import rhpl.arch; print rhpl.arch.canonArch"
The macros file with transaction color gets written if the above says x86_64 but
not if it's ia32e like reported on Intel x86_64 systems. 
Comment 3 Philippe Troin 2007-12-07 17:06:50 EST
Ok, this line can be safely deleted then.
Thanks for the info.


Note You need to log in before you can comment on or make changes to this bug.