Hi Richard and Mark, > -----Original Message----- > From: [email protected] > [mailto:[email protected]] 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 <[email protected]> > > > > 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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
