Comment 11 for bug 1172334

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.