3864 2013-02-07 14:50:35 +0000 smart installer prefers i586 over core2 in repository 2013-09-02 15:30:48 +0000 1 1 11 Runtime Package Management Issues package-management-issues 1.4 E-Menlow x86_64 VERIFIED FIXED Medium+ normal 1.4 M5 1 corneliux.stoicescu bogdan.a.marinescu bluelightning bogdan.a.marinescu elizabeth.flanagan n3npq sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 29642 0 corneliux.stoicescu 2013-02-07 14:50:35 +0000 BUILD: 1.4_M3:3ae1a4ba972cfc17ff3f2fda632da8ecc3414885 META-INTEL: 4f676959c35cbd0ed9ac6a1817993d38611859e1 ENVIRONMENT: Emenlow STEPS TO REPRODUCE: 1)Add a rpm-md channel with smart. Make sure this channel and the default rpm-sys channel are enabled. (I used the autobuilder repository, example: http://autobuilder.yoctoproject.org/pub/nightly/20130131-4/rpm/ ) 2)Run "smart update" to update the channel information. 3)Run "smart install package_name" to install a package from the remote repository. For example, "smart install groff" . Notice the architecture used is i586 even though core2 is present and it should prefer that. Please note that building an emenlow uses only core2 rpm . 30066 1 corneliux.stoicescu 2013-02-25 10:32:03 +0000 Update: I see the repodata folder was moved to rpm/<architecture> . Is this correct? As it stands now, smart can correctly install packages with core2 architecture. 30068 2 bluelightning 2013-02-25 10:40:38 +0000 That part is correct, yes. For the purposes of rootfs construction, keeping separate indexes for each architecture helps when switching between machines - you don't need to re-create the whole index just to include/exclude some of the architectures. 30124 3 corneliux.stoicescu 2013-02-26 13:06:08 +0000 With a repodata structure similar to the one we had before this change, could this become an issue with other rpm repositories? If now, please set this to NOTABUG. 30127 4 bluelightning 2013-02-26 13:34:21 +0000 Assuming there is a correct /etc/rpm/platform created for the image, Smart should be able to install the correct package even if there is only one index; it seems from the report that it cannot do that, so as far as I'm concerned the bug is still valid. We have our own reasons for using one index per locale, but that doesn't mean it's acceptable to force users to do the same just to get the correct architecture priority behaviour. 30128 5 bluelightning 2013-02-26 13:34:43 +0000 Er, one index per architecture, not locale. Reading too many things at once... 31526 6 bogdan.a.marinescu 2013-04-04 14:34:12 +0000 I can't find 20130131-4 on the autobuilder anymore, is the repository available from somewhere else? 31541 7 sgw 2013-04-04 15:13:24 +0000 Check with Beth 31597 8 corneliux.stoicescu 2013-04-05 09:26:57 +0000 You can use the information in https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=419 to create your own repository and images by using the commits from my post. 31619 9 elizabeth.flanagan 2013-04-05 16:12:21 +0000 No, 20130131 is over two months old. Long gone. 31901 10 bogdan.a.marinescu 2013-04-11 11:11:17 +0000 This is how /etc/rpm/platform looks like for emenlow: i586-poky-linux emenlow-.*-linux core2-.*-linux i686-.*-linux i586-.*-linux i486-.*-linux i386-.*-linux x86-.*-linux noarch-.*-linux.* any-.*-linux.* all-.*-linux.* So I'm guessing the problem is not in smart, but in the way /etc/rpm/platform is generated. I don't know much about /etc/rpm/platform and a google search didn't reveal much information, so I'm still looking into this. 32566 11 bogdan.a.marinescu 2013-04-24 08:56:58 +0000 Patch sent (rpm: change arch scoring items). 32604 12 n3npq 2013-04-24 17:05:39 +0000 The /etc/rpm/platform file determines arch scoring. The first line is a string that identifies CPU-VERSION-OS-GNU. The remaining lines are regex patterns. The patterns are applied to the RPMTAG_PLATFORM tag string in *.rpm packages. The line number of the first pattern that matches is the arch score. smart SHOULD prefer the package with the lowest score. 32715 13 bogdan.a.marinescu 2013-04-29 14:01:31 +0000 Patch merged. 36165 14 corneliux.stoicescu 2013-09-02 15:30:48 +0000 This is verified in master:5745e45b18e5099e94b4d5a73bc97dc6d4cdc91f (sorry for the delay; this has been working for quite a while)