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

[Xu, Dongxiao]

Hi Richard and Mark,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Wednesday, September 21, 2011 5:50 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH
> for multilib recipes
> 
> 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...

I have an updated commit in http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dxu4/ml4&id=6b2ed895e25bf6d76cc362c87661fd66231c4b4a

You can cherry-pick that to your pull request.

Thanks,
Dongxiao

> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core