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

Tue Apr 23 13:35:43 UTC 2013

I've sent another patch that attempts to fix the same bug in a different
way ('rpm: change arch scoring items'). Please review it.

Thanks,
Bogdan

On Tue, Apr 23, 2013 at 1:11 PM, Marinescu, Bogdan A <
bogdan.a.marinescu at intel.com> wrote:

> 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/b70795e1/attachment-0002.html>