tree/branch: poky/denzil commit: 2c3d4f5beee8f57a74244495511b9294df1085ea I find that with denzil branch, when I build something with MACHINE set to qemux86 and build a core2 based image, for example, crownbay, then some i586 packages will be installed into crownbay image. This is casued that PACKAGE_ARCHS is set to "all any noarch x86 i386 i486 i586 i686 core2 crownbay" in such case. To reproduce the issue, I use following steps: 1. download poky source code 2. build a sato image against qemux86 3. download meta-intel and build crownbay under the same build environment
Which packaging type showed this failure and does it fail with the other package managers?
(In reply to comment #1) > Which packaging type showed this failure and does it fail with the other > package managers? I only tested RPM with this case and did not try others. Let me have a check and will give an update.
I tested ipk, some i586 packages are also installed into crownbay image.
I've tested the up to date denzil branch, but can't reproduce it. tree/branch: poky/denzil commit: 3bf8069100e54153d13319dc32ca089327b6a139 PACKAGE_CLASSES ?= "package_rpm" build core-image-sato with MACHINE=qemux86 build core-image-sato with MACHINE=crownbay $ ./tmp/sysroots/i686-linux/usr/bin/rpm -qa --root /buildarea2/lyang1/den/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/rootfs --dbpath /var/lib/rpm --qf '%{ARCH}\n' | grep i586 There is no output. Did I miss anything, please?
It's strange, I tested with the commit you used and could not reproduce the bug any more.
(In reply to comment #5) > It's strange, I tested with the commit you used and could not reproduce the > bug any more. Thanks Jiajun, I will mark it as RESOLVED->WORKSFORME.
I can reproduce it with Jiajun help now, information from Jiajun: I built core-image-sato-sdk for qemux86 and then core-image-sato for crownbay. Then I find diffutils-3.2-r0.i586 is installed into crownbay. Maybe you could have another try on your side? If you have not removed previous build environment, you could just change MACHINE to qemux86 and build a core-image-sato-sdk and build core-image-sato for crownbay to see if it could be reproduced.
This is because the rpm automatically select the newest built rpm, from rpm-native-5.4.0-r36/rpm-5.4.0/lib/rpmts.c: /* XXX Prefer the newest build if given alternatives. */ he->tag = RPMTAG_BUILDTIME; xx = headerGet(h, he, 0); htime = (xx && he->p.ui32p ? he->p.ui32p[0] : 0); he->p.ptr = _free(he->p.ptr); The difftuils.586.rpm is newer than diffutils.core2.rpm, so the difftuils.586.rpm is going to be installed. I'm curious that it doesn't regard to the ARCH. I think that there are two ways to fix this problem: 1) Don't let the unneeded arch in PACKAGE_ARCHS 2) Fix rpm's selecting mechanism I prefer the first one, and will go on working on it. // Robert
I've sent the pull request for rpm based rootfs, but the ipk also has the similar problem, and they are not caused by the same reason, for the rpm, it would select the newest build pkg and doesn't respect to the arch. For ipk, we have set the arch priority , but its selecting priority is:(From high to low) 1) The pkg provided by hand 2) The pkg's name which matches the needed name(not very sure about this, still in investigating), use the highest version if given alternatives 3) The held pkg 4) Respect to the arch priority 5) Use the latest one I think that the 2) and 4) should be exchanged, then our problem would be fixed. I will go on working on it tomorrow. The deb based rootfs is still in testing.
(In reply to comment #9) > I've sent the pull request for rpm based rootfs, but the ipk also has the > similar problem, and they are not caused by the same reason, for the rpm, it > would select the newest build pkg and doesn't respect to the arch. For ipk, > we have set the arch priority , but its selecting priority is:(From high to > low) > > 1) The pkg provided by hand > 2) The pkg's name which matches the needed name(not very sure about this, > still in investigating), use the highest version if given alternatives > 3) The held pkg > 4) Respect to the arch priority > 5) Use the latest one > > I think that the 2) and 4) should be exchanged, then our problem would be > fixed. I will go on working on it tomorrow. > > The deb based rootfs is still in testing. Fortunately, the deb rootfs doesn't have the similar problem. The rpm part has been merged, and I have sent the pull request for the ipk, and only change the second selecting method rather than exchange the second and the forth.
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
The rpm part has been fixed: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=bb4f829965682f7879883dbf788ea03954b13bb5 Please see 2575 for the opkg part: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2575
Verified with master branch: 7f017cab0b3e4d5a4fc356eccd8eb8429b0531d0 Steps: 1. bitbake diffutils with MACHINE=crownbay 2. bitbake diffutils with MACHINE=qemux86 in same build directory. 3. bitbake core-image-sato with MACHINE=crownbay in same build directory. 4. Check the tmp/work/crownbay_noemgd-poky-linux/core-image-sato-1.0-r0/temp/install_solution.manifest. The core2 package should be installed but no i585 package. Will verify with 1.2.1 later.
Verified on 1.2.1 Tree/Branch: poky/denzil Poky Commit: 73cdebf60df225ee10f2eb215935be3b61e1b831