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

[Mark Hatle]

On 9/12/11 9:39 PM, 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: 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?

I can't think of a better solution for this right now.  Note, that if the
MLPREFIX is added to the MACHINE_ARCH, a corresponding change to Zypper will be
needed as well.

--Mark

> 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
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core