On 4/18/13 11:59 AM, Richard Purdie wrote:
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.marine...@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.
Ordering is defined by the lines -after- the first one.. the first line is
defined as the system arch.
The function rpmPlaform(...) in lib/rpmrc.c controls the loading of this data.
The first time through is reads the first line and sets:
_platform_cpu
_platform_vendor
_platform_os
_platform_gnu
The _platform items are used by the "_host_*" requivalent macros.. this defines
the core system items.
Subsequent lines are then loaded and added to the regex for 'supported'
platforms/package archs. (The 'arch' field in a package is useless.. it's just
a key but doesn't really mean anything in RPM 5. It's the 'platform' field
embedded into the package that is actually used for compatibility.)
The machine ordering SHOULD come from the 'platformScore' function (also in
lib/rpmrc.c). That only uses the regex to figure out the proper 'score' for a
component. (roughly matches the line number in the file)
That being said, this stuff doesn't actually affect smart -directly-, it only
affects it indirectly. When a package is selected by smart (which has it's own
ordering tools) it verified compatibility using these components.
For image generate, the package order is defined by us adding the places to look
one at a time. The only place I've seen a similar problem is when someone moves
all of the packages into a single directory and says 'here ya go'. I don't know
how smart selects which packages to favor in that case. If someone could point
that out, it may turn out it's a bug in smart -- or a problem we need to fix in
another way.
There is a python function 'archScore'. What this does is take the package arch
passed into the function, add the vendor/os from the platform (first line). It
then calls the rpmPlatformScore function to get a response.
But the first of removing the first line is simply wrong. It has to be set to
something that represents the system and is 'similar' to uname -m, as that value
may be attempted to be passed into configure or other tools if someone uses
'rpmbuild' on their target.
--Mark
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
