From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation
Date: Thu, 18 Apr 2013 17:59:06 +0100 [thread overview]
Message-ID: <1366304346.10502.77.camel@ted> (raw)
In-Reply-To: <51700CF8.5030600@windriver.com>
On Thu, 2013-04-18 at 10:10 -0500, Mark Hatle wrote:
> On 4/18/13 9:46 AM, Mark Hatle 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@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.)
>
> Forgot one thing. The first line must be fully expanded. Subsequent lines are
> regex matched by the system.
We have a problem here since the machine specific packages are meant to
be preferred over the "tune" specific ones by definition of the way OE
has long since worked, the structure of the PACKAGE_ARCHS variable and
so on.
As I understand it, this will not happen with this file setup in this
way.
Cheers,
Richard
next prev parent reply other threads:[~2013-04-18 17:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 14:27 [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation Bogdan Marinescu
2013-04-18 14:46 ` Mark Hatle
2013-04-18 15:10 ` Mark Hatle
2013-04-18 16:59 ` Richard Purdie [this message]
2013-04-18 17:32 ` Mark Hatle
2013-04-19 12:18 ` Richard Purdie
2013-04-22 12:00 ` Marinescu, Bogdan A
2013-04-22 14:34 ` Marinescu, Bogdan A
2013-04-23 10:11 ` Marinescu, Bogdan A
2013-04-23 13:35 ` Marinescu, Bogdan A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366304346.10502.77.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox