| Summary: | smart installer prefers i586 over core2 in repository | ||
|---|---|---|---|
| Product: | [Runtime] Package Management Issues | Reporter: | Stoicescu Cornel <corneliux.stoicescu> |
| Component: | package-management-issues | Assignee: | Bogdan Marinescu <bogdan.a.marinescu> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bluelightning, bogdan.a.marinescu, elizabeth.flanagan, n3npq, sgw |
| Version: | 1.4 | ||
| Target Milestone: | 1.4 M5 | ||
| Hardware: | E-Menlow | ||
| OS: | x86_64 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Stoicescu Cornel
2013-02-07 14:50:35 UTC
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. 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. 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. 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. Er, one index per architecture, not locale. Reading too many things at once... I can't find 20130131-4 on the autobuilder anymore, is the repository available from somewhere else? Check with Beth 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. No, 20130131 is over two months old. Long gone. 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. Patch sent (rpm: change arch scoring items). 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. Patch merged. This is verified in master:5745e45b18e5099e94b4d5a73bc97dc6d4cdc91f (sorry for the delay; this has been working for quite a while) |