[OE-core] [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation

Tue Apr 23 10:11:10 UTC 2013

I've investigated this issue further. /etc/rpm/platform is parsed in
rpmrc.c/rpmPlatform. It is true that the first line of /etc/rpm/platform
does not get added directly to the platform list, being passed to parseCVOG
instead, but after parserCVOG ends, it is added to the platform list
anyway, although indirectly (mireAppend with the result of rpmExpand).
After that, it stays in the platform list and it matched on subsequent
calls to rpmPlatformScore, so it definitely has an impact on the way smart
chooses the platform for a package. So, with all this in mind, where is the
bug here? Is it in the RPM library or we really should not add that first
line to the /etc/rpm/platform file?

Thanks,
Bogdan

On Mon, Apr 22, 2013 at 5:34 PM, Marinescu, Bogdan A <
bogdan.a.marinescu at intel.com> wrote:

> Further investigation reveals the fact that the problem is connected to
> the value returned by "rpm.archscore", which changes with the value of the
> first line of /etc/rpm/platform. I'm testing under qemux86 and editing
> /etc/rpm/platform by hand. I've traced the code to backends/rpm/base.py
> which contains the function getArchScore (which basically calls
> rpm.archscore). With this /etc/rpm/platform:
>
> i586-poky-linux
> core2-.*-linux
> qemux86-.*-linux
> i586-.*-linux
> .......
>
> I get a score of 2 for arch core2 and 1 for i586. If I remove the first
> line (i586-poky-linux) and rerun smart without chaning anything else, I get
> a score of 1 for arch core2 and a score of 3 for i586. So that line
> definiteley matters, which should be a bug, if I understood Mark's e-mails
> correctly.
>
> Thanks,
> Bogdan
>
>
>
> On Mon, Apr 22, 2013 at 3:00 PM, Marinescu, Bogdan A <
> bogdan.a.marinescu at intel.com> wrote:
>
>> On Thu, Apr 18, 2013 at 5:46 PM, Mark Hatle <mark.hatle at windriver.com>wrote:
>>
>>> On 4/18/13 9:27 AM, Bogdan Marinescu wrote:
>>>
>>>> For some platforms (for example emenlow) the RPM installer prefers
>>>> an invalid package architecture (for example i586 over core2) because
>>>> /etc/rpm/platform is not properly generated (for example, i586 is
>>>> listed before core2 in /etc/rpm/platform).
>>>>
>>>> [YOCTO #3864]
>>>>
>>>> Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu at intel.com>
>>>> ---
>>>>   meta/classes/package_rpm.**bbclass |    1 -
>>>>   1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/meta/classes/package_rpm.**bbclass
>>>> b/meta/classes/package_rpm.**bbclass
>>>> index 3a29976..1bee4b1 100644
>>>> --- a/meta/classes/package_rpm.**bbclass
>>>> +++ b/meta/classes/package_rpm.**bbclass
>>>> @@ -276,7 +276,6 @@ package_install_internal_rpm () {
>>>>                 # Setup base system configuration
>>>>                 echo "Note: configuring RPM platform settings"
>>>>                 mkdir -p ${target_rootfs}/etc/rpm/
>>>> -               echo "$INSTALL_PLATFORM_RPM" > ${target_rootfs}/etc/rpm/
>>>> **platform
>>>>
>>>
>>> I think this is wrong.  The /etc/rpm/platform file's first line is
>>> supposed to be the equivalent of: [uname -m]-vendor-os.   While uname -m
>>> doesn't match our tune namings, the concept is the same.  The first line
>>> simply defines the "tune" of the platform, subsequent lines define
>>> alternative names that will run on this system.
>>>
>>> The INSTALL_PLATFORM_RPM value should be the expected value for the
>>> platform as a whole, as it's the default tune value.  (Default tune value
>>> is expected to be the most accurate value.
>>>
>>> Looking at the defect:
>>>
>>> i586-poky-linux
>>> emenlow-.*-linux
>>> core2-.*-linux
>>> i686-.*-linux
>>> i586-.*-linux
>>> i486-.*-linux
>>> i386-.*-linux
>>> x86-.*-linux
>>> noarch-.*-linux.*
>>> any-.*-linux.*
>>> all-.*-linux.*
>>>
>>> The default tune value for that machine was set to i586 by "something".
>>>
>>> INSTALL_PLATFORM_RPM="$(echo ${TARGET_ARCH} | tr -
>>> _)${TARGET_VENDOR}-${TARGET_**OS}"
>>>
>>> ${TARGET_ARCH} is similar to the output of uname -m.  The error is that
>>> this particular BSP should have returned 'core2' as the TARGET_ARCH from
>>> what I can tell.
>>>
>>> Default for TARGET_ARCH is: TARGET_ARCH = "${TUNE_ARCH}"
>>>
>>> So the TUNE_ARCH is being set to i586.  So the end result is..  Is
>>> 'TUNE_ARCH' set to i586 appropriate?  It probably is, because the majority
>>> of the system seems to have a limited set of expected values for
>>> TARGET_ARCH.
>>>
>>> So, perhaps the right fix is instead of using 'TARGET_ARCH' in
>>> INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more appropriate.
>>>
>>> I'd suggest trying that.  (But the first line is the system
>>> architecture, following lines are alternative packages that are considered
>>> compatible.)
>>>
>>>
>>>
>>>>                 if [ ! -z "$INSTALL_PLATFORM_EXTRA_RPM" ]; then
>>>>                         for pt in $INSTALL_PLATFORM_EXTRA_RPM ; do
>>>>
>>>>
>>>
>> On my qemux86 image, /etc/rpm/platform looks like this:
>>
>> qemux86-.*-linux
>> i586-.*-linux
>> i486-.*-linux
>>  i386-.*-linux
>> x86-.*-linux
>> noarch-.*-linux.*
>> any-.*-linux.*
>> all-.*-linux.*
>>
>> The first line is not fully expanded and smart seems to make the correct
>> choice of packages in this case.
>>
>> Thanks,
>> Bogdan
>>
>>
>>>
>>> ______________________________**_________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.**openembedded.org<Openembedded-core at lists.openembedded.org>
>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>> openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130423/9a50c0d9/attachment-0002.html>