| Summary: | image does not contain all RDEPENDS with package_rpm | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jussi Kukkonen <jku> |
| Component: | core | Assignee: | Jussi Kukkonen <jku> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | alex.kanavin, meta.mr.watcher, meta.watcher |
| Version: | 2.3 | ||
| Target Milestone: | 2.3 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Jussi Kukkonen
2017-04-19 10:31:54 UTC
va-intel.spec looks like this: --- Summary: va-intel version 1.0-r1 Name: va-intel Version: 1.0 Release: r1 License: MIT Group: base Packager: Poky <poky@yoctoproject.org> BuildRequires: virtual/libc BuildRequires: virtual/x86_64-poky-linux-compilerlibs BuildRequires: virtual/x86_64-poky-linux-gcc Requires: libva Requires: libva-intel-driver %description Video Acceleration Add-ons for Intel BSPs %files %defattr(-,-,-,-) --- yet when I check on the image: --- # rpm -q --requires va-intel libva rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 --- The image seemsto pick core2_64 version of the va-intel package even though bitbake built the corei7_64. Starting from empty TMPDIR: $ MACHINE=intel-corei7-64 bitbake core-image-sato $ MACHINE=qemux86-64 bitbake core-image-sato $ MACHINE=intel-corei7-64 bitbake -ccleansstate core-image-sato $ MACHINE=intel-corei7-64 bitbake core-image-sato The first and last images will have completely different manifests: the first one has 0 core2_64 packages, the last one has 583 core2_64 packages. (the above doesn't actually show the va-intel problem because va-intel doesn't get built for qemux86-64 by default, but the reasons are the same) PACKAGE_ARCHS="all any noarch x86_64 core2-64 corei7-64 corei7-64-intel-common intel_corei7_64" So apparently PACKAGE_ARCHS is supposed to be ordered (right-most first), and dnf does not seem to do that. (In reply to comment #3) > PACKAGE_ARCHS="all any noarch x86_64 core2-64 corei7-64 > corei7-64-intel-common intel_corei7_64" > > So apparently PACKAGE_ARCHS is supposed to be ordered (right-most first), > and dnf does not seem to do that. The architectures' whitelist is written into rootfs/etc/dnf/vars/arch. What happens if you reverse it? (In reply to comment #4) > The architectures' whitelist is written into rootfs/etc/dnf/vars/arch. What > happens if you reverse it? This did the trick: correct packages are now getting installed into the rootfs in all my test cases. I've sent a patch so I guess I'll take the bug for now... Let's see if I end up regretting this. commit adea8003abe383b9bc532ac5477bc274e270c19a Author: Jussi Kukkonen <jussi.kukkonen@intel.com> Date: Wed Apr 19 16:25:57 2017 +0300 package_manager.py: Reverse rpm arch order The architecture list used by dnf/libsolv was in the wrong order. As a result, the images were built with wrong and unpredictable packages. $ MACHINE=intel-corei7-64 bitbake core-image-sato $ MACHINE=qemux86-64 bitbake core-image-sato $ MACHINE=intel-corei7-64 bitbake -ccleansstate core-image-sato $ MACHINE=intel-corei7-64 bitbake core-image-sato The first image had 0 core2_64 packages in it, but the last one had 583 core2_64 packages (which were built for the qemu image in between). Reverse the arch order in etc/dnf/vars/arch. Fixes [YOCTO #11384]. (From OE-Core rev: 4a82433de42943f8219beca3286f40b67157172f) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |