[OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes

[Richard Purdie]

On Tue, 2011-09-20 at 16:33 -0500, Mark Hatle wrote:
> From: Dongxiao Xu <dongxiao.xu at intel.com>
> 
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package will override a normal rpm package if its
> PACKAGE_ARCH is ${MACHINE_ARCH}.
> 
> Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH. Both
> the normal version of netbase package and the lib32 version are named as
> "netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64
> directory, so we need to differentiate them.
> 
> Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
> the default MACHINE value, thus got different MACHINE_ARCH to fix this
> issue.

We simply *cannot* do this and this patch cannot be merged. I thought
I'd explained this once but I will try and do so again.

The problem is MACHINE specific packages can have generic content. They
may have binaries, libraries or other things contained within them. Lets
assume we have a strange system which has files in /lib, /lib32
and /lib64. We need the following permutations:

qemux86 /lib
qemux86 /lib64
qemux86 /lib32

and these are not equal to:

qemux86_64 /lib
qemux86_64 /lib64
qemux86_64 /lib32

which may or may not have different contents or different optimisations
applied to the binaries/libraries contained within.

You are trying to take a shortcut here and cross link these two sets and
that doesn't scale to generic combinations. 

Furthermore, MACHINE is meant to be consistent within a given build and
changing MACHINE for different multilibs will have all kinds of
unintended consequences (such as the cache file location changing for
different recipes).

Wasn't there an alternative proposal from Dongxiao that added MLPREFIX
to MACHINE_ARCH and resolved this issue that way instead? I know that
causes issues at the package management level but I think we're going to
have to run with that approach and resolve any issues it leads to...

Cheers,

Richard