Preconditions/Environment ------------------------- Tested on latest kirkstone (c4e08719a7). local.conf changes: PACKAGE_CLASSES ?= "package_ipk" IMAGE_INSTALL:append = " postgresql" Triggering Action/Cause ----------------------- MACHINE=qemuarm64 bitbake core-image-minimal -c do_populate_sdk Happens also on other machines. Expectation ----------- bitbake should populate the SDK successfully. Actual Result ------------- ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Unable to install packages. Command '/path/to/bsp/build/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /path/to/bsp/build/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/opkg-sdk-target.conf -t path/to/bsp/build/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/temp/ipktemp/ -o path/to/bsp/build/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk/image/usr/local/oe-sdk-hardcoded-buildpath/sysroots/cortexa57-poky-linux --force_postinstall --prefer-arch-to-version install packagegroup-core-boot packagegroup-core-standalone-sdk-target postgresql run-postinsts target-sdk-provides-dummy' returned 1: * Solver encountered 1 problem(s): * Problem 1/1: * - package target-sdk-provides-dummy-1.0-r0.sdk-provides-dummy-target conflicts with perl provided by perl-5.34.1-r0.cortexa57 * - package postgresql-14.4-r0.cortexa57 requires perl >= 5.34.1, but none of the providers can be installed * - conflicting requests * - conflicting requests * * Solution 1: * - do not ask to install a package providing target-sdk-provides-dummy * Solution 2: * - do not ask to install a package providing postgresql Reproducibility --------------- Reproducible every time. Investigation/Workaround ------------------------ This does *not* happen with PACKAGE_CLASSES ?= "package_rpm". Other package management methods (other than ipk) seem to be affected also, see bug tickets below. For the ipk case, the perl package provided by target-sdk-provides-dummy is not considered. As a work-around target-sdk-provides-dummy's PV can be set to a higher value than perl's required version, e.g.: PV = "6.0" (PV is unset by default, so it evaluates to "1.0", which is lower than what's expected). This makes the above bitbake command succeed, but only if opkg is configured without libsolv (e.g. PACKAGECONFIG = ""). My current guess is that different package managers (at least in some cases also depending on their PACKAGECONFIG) handle the RPROVIDES/RCONFLICTS/RREPLACES set in meta/recipes-core/meta/dummy-sdk-package.inc differently than others. I think the above error happens because the perl version required has that minimum version (>= 5.34.1). Some package management methods seem to respect the version, others do not. The way target-sdk-provides-dummy provides these dummy packages does not seem to work for all cases. Probably similar to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13338 https://bugzilla.yoctoproject.org/show_bug.cgi?id=14066
Postgresql isn't part of oe-core: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-dbs/postgresql/postgresql_14.5.bb?h=master but we'll take the bug to investigate. Do you expect perl to be installed in the SDK or are you trying to avoid having perl installed in the SDK? Does the postgresql recipe have any perl modules that it depends on?
(In reply to comment #1) > Postgresql isn't part of oe-core: > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-dbs/ > postgresql/postgresql_14.5.bb?h=master Ah, you're right. Sorry about that. The problem happens on latest kirkstone state of meta-openembedded (a8055484f). > but we'll take the bug to investigate. Thanks! > Do you expect perl to be installed in the SDK or are you trying to avoid > having perl installed in the SDK? postgresql is part of an image, but it's not really used in the SDK, I guess. So the dummy perl package is okay, we don't really need it. I still think that do_populate_sdk should work on that particular image. > Does the postgresql recipe have any perl modules that it depends on? Hm, I don't see any, but I am really not that deep into postgresql. These commits' messages also involve postgresql, by the way: bc060556c5 ("target-sdk-provides-dummy: add libperl.so.5 to DUMMY_PROVIDES") 0729bda024 ("target-sdk-provides-dummy: add libperl.so.5 64bit")
I received an email that said I should update the state of the bug when the information requested was provided. I don't know what the correct status would be, so I set it to "accepted". If that's incorrect, please update the status.
We want to review this bug at the weekly bug review meeting so setting the state to new and owner to unassigned.
Tim will take a look.
Reproduced the error.
Confirmed also affects package_deb (but not package_rpm): ERROR: core-image-minimal-1.0-r0 do_populate_sdk: Unable to install packages. Command '.../build-postgresql-sdk/build/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/apt-get install --allow-downgrades --allow-remove-essential --allow-change-held-packages --allow-unauthenticated --no-remove packagegroup-core-boot packagegroup-core-standalone-sdk-target postgresql run-postinsts target-sdk-provides-dummy' returned 100: Reading package lists... Building dependency tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: target-sdk-provides-dummy : Conflicts: perl Conflicts: perl-module-config Conflicts: perl-module-strict Conflicts: perl-module-vars Conflicts: perl-module-warnings Conflicts: perl-module-warnings-register E: Unable to correct problems, you have held broken packages.
Looking at 13338 and 14066 concerns me as it seems to be a long time problem, but in the bug triage meeting we discussed that a larger systemic problem is unlikely or it would have been caught in buildtools tarball. Handing this off to RP for further look, as I don't quite know what is happening.
It turns out the issue is exactly what the error says. There is a dependency on "perl >= 5.34.1" which is injected by the shlibs code during do_package and target-sdk-provides-dummy provides perl but doesn't have a version greater than 5.34.1. To prove this was the issue I added this hack on a test on master: diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index c9eb75d8523..867f8474201 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -1778,6 +1778,9 @@ def process_shlibs(pkgfiles, d): if dep_pkg == pkg: continue + if dep_pkg == "perl": + ver_needed = False + if ver_needed: dep = "%s (>= %s)" % (dep_pkg, ver_needed) else: (on kirkstone the same code is in package.bbclass) and then the test case succeeds (master had the same error as kirkstone with a slightly different perl version). So we have two options. We either drop the version in shlibs for some set of targets (configurable list?), or we bump the version (or package epoch?) on the target-sdk-provides to something suitably high. I'm open to other ideas!
As further notes, setting perl (= 5.34.1) in the dummy recipe does make the appropriate entry in the dummy rpm but the populate_sdk still fails. Increasing the PV and PE of the dummy rpm doesn't seem to help either. The only way I've made the build succeed so far is to remove the version constraint on perl.
I think my previous testing was flawed. What might fix rpm is: +RPROVIDES:${PN} = "perl (= 5.999)" +RREPLACES:${PN} = "perl" and removing perl from DUMMYPROVIDES_PACKAGES but that then breaks deb and ipk generation of the SDK. We need to work out what combination works correctly for all the backends.
Note: rpm works because architecture of conflicting packages was not specified. generated rpms have different architecture: $ rpm -qip cortexa57/perl-5.34.1-r0.cortexa57.rpm Name : perl Version : 5.34.1 Release : r0 Architecture: cortexa57 $ rpm -qip sdk_provides_dummy_target/target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target.rpm Name : target-sdk-provides-dummy Version : 1.0 Release : r0 Architecture: sdk_provides_dummy_target and thus they are parallel installable. Perl+postgresql can be installed with target-sdk-provides-dummy and dependencies are satisfied. Which not the case of deb and ipk and it explains why it fails. To have deb package parallel installable Multi-Arch: foreign must be specified but it will break the entire idea of "Conflicts/Provides" in the dummy package. Investigating more.
Looks like the root cause of this bug on ipk and deb are different. In case of ipk perl-%{version}.ipk conflicts with unversioned version of perl which provides by dummy. In other words it fails even without CONFLICTS and REPLACES in target-sdk-provides-dummy.
Bulk move of 5.1 bugs to 5.2. -- YP bug review (Randy)
Fix for this bug have been submitted but caused issues in the SPDX tasks. I'm not sure how to proceed with this bug now.
Bumping to 6.1-M2. For anyone interested, Pavel hasn't been able to work on YP recently so ask / assign this bug to yourself if you want to pick up where Pavel left off. I'll move the bug owner to unassigned.
(In reply to Randy MacLeod from comment #16) > Bumping to 6.1-M2. > > For anyone interested, Pavel hasn't been able to work on YP recently > so ask / assign this bug to yourself if you want to pick up where Pavel > left off. I'll move the bug owner to unassigned. In addition to Randy's comment. Patches for this one (and few other related bugs) have been submitted but caused SPDX failures in AB we didn't understand. Worth retesting the patches with current master to see if spdx has been fixed... I was not able to reproduce the failures without AB env.
Pavel, did the patches for this get any further?