Support x32 rpm

H. J. Lu's patch is crap: the better implementation uses
another color bit.

where is that better implementation?

also, would you use same color for x32 same as i686, or new one?

in pld linux i was thinking to use new color:
- 1 - i386
- 2 - x86_64
- 3 - x32

and also would use "lib32" as %{_lib}:
- i686 - lib
- x86_64 - lib64
- x32 - lib32

Adding a color bit is minimal necessary change: H. J. Lu's dependency
patch is crap.

Note that "3" == 0b011 isn't a color bit. It's entirely
possible (even if insanely unlikely) to have all of i386/x86_64/x32
set in the same file

Adding a color bit forces a reorganization to better classification.
There aren't bits left. And other means than "color" need to be
devised.

i see such possible scenario:

1. /usr/bin/foo owned by foo.x86_64
2. /usr/bin/foo owned by foo.i686
3. /usr/bin/foo owned by foo.x32

and i would prefer if it worked identically to:
1. /usr/bin/foo owned by foo.x86_64
2. /usr/bin/foo owned by foo.i686

i.e:

1. all three packages are installable, no file-conflict error
2. some preference of which binary will be placed

for x86_64 vs x32/i686 it's simple, but if i have x32 vs i686 binaries to decide, which one will "win"? x32 probably? or i686?

if color is a bit, then yea, "4" it should be, i'm not arguing this! :)

Yes the 0x4 bit is available (and in use on MIPS for the 3rd
"other endian" architecture.

The "preferred" color is settable through a macro. With 3 color bits,
the macro would need to become a list with 1st:2nd:3rd preference choices.

The ugliest part of H.J. Lu's patch is that the patch is propagating a useless "…()…"
marker in dependencies like

   Requires: libfoo.sp()(64bit)

With colors, the (64bit) is equally unnecessary because dependencies
match against other dependencies of the same color first. There are likely
consequences for depsolvers like polder which have never implemented
dependency (or file) colors correctly.

does rpm5 plan to add working support for x32 anytime soon? or should pld try to do it by it own?

I've done some initial integration of H.J. Lu's stuff (which quite frankly I wouldn't consider state of the art myself neither) in mandriva branch, and some bootstrap parts to the toolchain..
I've built a whole tri-arch i686/x86_64/x32 toolchain , although only commited some of the parts to rpm and the bootstrap part to our gcc package..

But mainly just been killing time with no serious efforts on my part yet, I'd be more interested in achieving some less hackish and in collaboration with others having interest in sharing the workload.. :)

In commen to the mips coloring bit, I assume that one are to be considered free for use for this purpose, where it's existing purpose on mips is already quite equivalent, no? :)