[OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under deploy/rpm

Xu, Dongxiao dongxiao.xu at intel.com
Tue Sep 13 02:39:24 UTC 2011


Hi Mark,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Tuesday, September 13, 2011 1:23 AM
> To: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under
> deploy/rpm
> 
> On 9/12/11 10:07 AM, Xu, Dongxiao wrote:
> > Hi Mark,
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces at lists.openembedded.org
> >> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf
> >> Of Mark Hatle
> >> Sent: Monday, September 12, 2011 10:56 PM
> >> To: openembedded-core at lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs
> >> under deploy/rpm
> >>
> >> On 9/12/11 3:34 AM, Dongxiao Xu wrote:
> >>> 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}.
> >>>
> >>> Define different deploy folder for multilib architectures to avoid
> >>> the confliction.
> >>
> >> I'm not sure I understand here.  Within the deployment directory is a
> >> set of directories for each RPM architecture.  Are you saying that we
> >> can get two packages that have different contents but the same RPM
> architecture?
> >>
> >
> > Yes, for example the netbase recipe, 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.
> 
> Wow, that is very broken.  I think part of the problem is that the arch is used to
> signify not only ABI (and optimizations), but also machine type in this case.
> 
> What we really need is an additional architecture type that handles machine
> specific packages for each multilib type.  I'm really not sure what they would
> be called or how it would work though.
> 
> Anyone have suggestions for naming and processing of these?  (I'm almost
> tempted to say "machine_lib")

In the weekend I had a talk with Richard and he suggested on adding MLPREFIX to MACHINE_ARCH to differentiate them.
Otherwise user need to define a new value for MACHINE_virtclass-multilib-lib32?

Thanks,
Dongxiao

> 
> --Mark
> 
> > Thanks,
> > Dongxiao
> >
> >> Can you give me an example of what is going wrong?
> >>
> >> --Mark
> >>
> >>> Signed-off-by: Dongxiao Xu <dongxiao.xu at intel.com>
> >>> ---
> >>>  meta/classes/multilib.bbclass   |    5 +++++
> >>>  meta/classes/rootfs_rpm.bbclass |    4 +++-
> >>>  2 files changed, 8 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/meta/classes/multilib.bbclass
> >>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644
> >>> --- a/meta/classes/multilib.bbclass
> >>> +++ b/meta/classes/multilib.bbclass
> >>> @@ -77,4 +77,9 @@ python __anonymous () {
> >>>      multilib_map_variable("PACKAGES_DYNAMIC", variant, d)
> >>>      multilib_map_variable("PACKAGE_INSTALL", variant, d)
> >>>      multilib_map_variable("INITSCRIPT_PACKAGES", variant, d)
> >>> +
> >>> +    package_arch = d.getVar("PACKAGE_ARCH", True)
> >>> +    machine_arch = d.getVar("MACHINE_ARCH", True)
> >>> +    if package_arch == machine_arch:
> >>> +        d.setVar("PACKAGE_ARCH", variant + "_" + package_arch)
> >>>  }
> >>> diff --git a/meta/classes/rootfs_rpm.bbclass
> >>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644
> >>> --- a/meta/classes/rootfs_rpm.bbclass
> >>> +++ b/meta/classes/rootfs_rpm.bbclass
> >>> @@ -218,7 +218,9 @@ python () {
> >>>              default_tune =
> >> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
> >>>              if default_tune:
> >>>                  localdata.setVar("DEFAULTTUNE", default_tune)
> >>> -            ml_package_archs += localdata.getVar("PACKAGE_ARCHS",
> >> True) or ""
> >>> +            localdata.setVar("MACHINE_ARCH", eext[1] + "_" +
> >> localdata.getVar("MACHINE_ARCH", False))
> >>> +            package_archs = localdata.getVar("PACKAGE_ARCHS",
> True)
> >> or ""
> >>> +            ml_package_archs += " " + package_archs
> >>>              #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1],
> >> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
> >>>      bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs,
> >> d)  }
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core at lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list