Please refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2360 The opkg backend will not be fixed, just file this bug for reference.
Mark it as won't fix. Here is a summary of the current status: 1) dpkg doesn't have this problem 2) rpm has been fixed 3) For the opkg, we may not fix it after many discussions, please see below for details: The opkg's problem is not the same as rpm, the opkg selects the higher version pkg and ignore the arch priority in such a case, the crownbay needs xserver-xorg*_1.9.3-r1.core2.ipk, and they are machine arch (core2), and there are xserver-xorg-*_1.11.2-r3_i586.ipk (tune arch, i586) in the feeds, so opkg will install xserver-xorg-*_1.11.2-r3_i586.ipk, this is incorrect, let opkg respect to the arch priority would fix the problem, but it may cause other problems if we fix this problem, for example: (Koen Kool said) broken-app_1.0_machine.ipk is in the feeds, being machine specific broken-apps author fixes the machine specific bits properly broken-app_2.0_i586.ipk hits the feeds and is not picked up There are a few possible solutions: (Koen Kool said) 1) Lock X to 1.9.3 for all compatible x86 archs in your DISTRO 2) Lock X to 1.11.2 for all compatible x86 archs in your DISTRO, live with the crownbay breakage 3) Only use a package manager with no notion of compatible archs (dpkg) or with strong version pinning (rpm) 4) Be really careful with the build sequence and structure your feed configs to not have compatible archs in their feed URIs 5) remove 'x11' from DISTRO_FEATURES I'd like to divide this bug into 2 on next Monday if you are OK with it: 1) This one is for rpm, and will mark it as fixed. 2) The other one is for opkg, will mark it as won't fix, and put the summary there. Please see the emails in openembedded-core@lists.openembedded.org if you are interested in it, the subject is: opkg 0.1.8: respect to the arch when choose the alternatives
I'd at least like to limit the opkg feeds to the known current ones at rootfs generation time so the opkg rootfs is consistent with what the build outputed.
(In reply to comment #2) > I'd at least like to limit the opkg feeds to the known current ones at > rootfs generation time so the opkg rootfs is consistent with what the build > outputed. Update: 1) We had tried to let the priority win the version, but this was not acceptable. 2) I'm afraid that limit the opkg feeds to the known current ones at rootfs generation time is not easy to do because of the multilib. 3) AFAIK, add something like "preferred version" to opkg.conf didn't work since opkg didn't have such an ability. 4) The task-core-x11-base depends on xorg-xserver, and the task-core-x11-base is a machine arch (e.g., crownbay) pkg, so I think that if we can pass the version information(Depends: xorg-xserver (= 1.9.3) to task-core-x11-base, the problem would be fixed, here are the draft design: a) Modify the function do_package_ipk in package_ipk.bbclass, if a package RDEPENDS on the pkg which has a PREFERRED_VERSION, then add the explicit depends version to the "Depends:" tag. b) It would be great if we have a variable to save all the PREFERRED_VERSION recipes, it seems that we don't have it currently. c) Generally speaking, the rpm and deb also need it, fortunately, they work well by now, so I will only fix this for ipk. d) If the user doesn't install the task-core-x11-base, but install the xorg-xserver, the problem may still happen since no pkg depends on the 1.9.3, and the higher version will be installed, I think that this a hard problem. Anyway, this fix will make the default behaviour works correctly. I will send a patch review for it later if you are OK with it.
Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4946185084abba516988f61a911bd60f61a49168
verified git commit 718eb85806e080d0b165344b272e531ef19421eb,git branch 1.3_M5.