| Message ID | 20250509211912.3286338-1-ohnatiuk@cisco.com |
|---|---|
| State | New |
| Headers | show |
| Series | package: disable renamed dependency error if allarch is overridden | expand |
On Fri, 9 May 2025 at 23:19, Oleksandr Hnatiuk via lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org> wrote: > allarch code is only triggered if PACKAGE_ARCH remains set to "all". > This is not the case under some circumstances, like in the case of > nativesdk class which overrides this variable. This error then breaks > nativesdk package groups which depend on renamed packages yet aren't > affected by allarch. Can you show steps to observe the issue please? Why isn't it seen in the test matrix? Alex
There was a report of this on yocto mailing list with detailed info 2 years ago, but nobody responded to it. See: https://lists.yoctoproject.org/g/yocto/topic/nativesdk_packagegroup_sdk_host/98365178
On Mon, 12 May 2025 at 11:31, Oleksandr Hnatiuk via lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org> wrote: > There was a report of this on yocto mailing list with detailed info 2 years ago, but nobody responded to it. > See: https://lists.yoctoproject.org/g/yocto/topic/nativesdk_packagegroup_sdk_host/98365178 Adding library-only packages to packagegroups is simply not currently supported. What is the use case for it? Alex
I will have to check why such packages are included. However, consider the following. Here are all the parts of this issue: * a packagegroup explicitly inherits packagegroup and nativesdk classes * same packagegroup depends on a package which is subject to dynamic package renaming * packagegroup.bbclass unconditionally (because of immediate expansion) inherits allarch.bbclass * nativesdk.bbclass overrides PACKAGE_ARCH with correct value, preventing code in allarch.bbclass from executing (because allarch.bbclass tests this variable before doing anything) * bitbake raises an allarch-specific error by testing whether allarch was ever inherited instead of whether any of its code was executed (see 4) Regardless of whether 2 is justified, the behavior in 3 and/or 5 is seems incorrect. allarch.bbclass is unique in that we cannot test if it is really used without checking the value of PACKAGE_ARCH. If we simply check via bb.data.inherits_class, we get false positives (again, see step 4). Thus, it is incorrect to issue an error for packagegroups that inherit allarch without also verifying that they are actually allarch via PACKAGE_ARCH. Without this extra check, the error is produced for packagegroups for which code in allarch.bbclass was never and will never be executed.
On Tue, 13 May 2025 at 12:30, Oleksandr Hnatiuk via
lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org>
wrote:
> a packagegroup explicitly inherits packagegroup and nativesdk classes
Why? I have to ask what is the use case for inheriting nativesdk in a
packagegroup then :)
Alex
You have the same approach in openembedded-core layer. See meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb > > SUMMARY = "Host packages for the standalone SDK or external toolchain" > inherit packagegroup > inherit_defer nativesdk >
On Wed, 14 May 2025 at 17:35, Oleksandr Hnatiuk via lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org> wrote: > You have the same approach in openembedded-core layer. > See meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb > > SUMMARY = "Host packages for the standalone SDK or external toolchain" > inherit packagegroup > inherit_defer nativesdk That does not answer the question, and oe-core doing it doesn't mean it's correct or necessary. Oe-core makes mistakes or forgets to clean up obsolete code too :) In this case, this packagegroup is bundled together with other packagegroups in the SDK code, and those other packagegroups don't inherit nativesdk: TOOLCHAIN_HOST_TASK ?= " \ nativesdk-packagegroup-sdk-host \ packagegroup-cross-canadian-${MACHINE} \ ${@bb.utils.contains('SDK_TOOLCHAIN_LANGS', 'go', 'packagegroup-go-cross-canadian-${MACHINE}', '', d)} \ ${@bb.utils.contains('SDK_TOOLCHAIN_LANGS', 'rust', 'packagegroup-rust-cross-canadian-${MACHINE}', '', d)} \ " Alex Alex
How would building packages for SDK work without inheriting nativesdk? All other packagegroups in this variable use $MACHINE to parametrize themselves, so they are not plain packagegroups either. Furthermore, they inherit cross-canadian which sets PACKAGE_ARCH in the same way nativesdk.bbclass does. I cannot know every single detail and history behind why oe-core works the way that it does. What I do know is that I cannot add certain packages to SDK packagegroup because an unrelated error check is producing a false positive because the possibility of an allarch override is not being accounted for.
Also, consider this * packagegroup.bbclass inherits allarch.bbclass - except when PACKAGE_ARCH is set before inheriting packagegroup * in order to do so, a nativesdk packagegroup must inherit nativesdk first * there is a native-last QA check which strongly suggests inheriting nativesdk last * nativesdk is inherited last via inherit_defer in nativesdk-packagegroup-sdk-host I see all of this as either very misleading at best or a mistake at worst.
On Mon, 19 May 2025 at 12:24, Oleksandr Hnatiuk via lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org> wrote: > > Also, consider this > > packagegroup.bbclass inherits allarch.bbclass - except when PACKAGE_ARCH is set before inheriting packagegroup > in order to do so, a nativesdk packagegroup must inherit nativesdk first > there is a native-last QA check which strongly suggests inheriting nativesdk last > nativesdk is inherited last via inherit_defer in nativesdk-packagegroup-sdk-host > > I see all of this as either very misleading at best or a mistake at worst. This is probably true. It does look like a pile of ad hoc fixups rather than an overall design and structure. Maybe it's possible to clean and simplify? I'd say if you resubmit the patch with all the extra research you did in the commit message, that would help review. I don't have objections anymore. Alex
On Tue, 2025-05-20 at 15:06 +0200, Alexander Kanavin via lists.openembedded.org wrote: > On Mon, 19 May 2025 at 12:24, Oleksandr Hnatiuk via > lists.openembedded.org <ohnatiuk=cisco.com@lists.openembedded.org> > wrote: > > > > Also, consider this > > > > packagegroup.bbclass inherits allarch.bbclass - except when PACKAGE_ARCH is set before inheriting packagegroup > > in order to do so, a nativesdk packagegroup must inherit nativesdk first > > there is a native-last QA check which strongly suggests inheriting nativesdk last > > nativesdk is inherited last via inherit_defer in nativesdk-packagegroup-sdk-host > > > > I see all of this as either very misleading at best or a mistake at worst. > > This is probably true. It does look like a pile of ad hoc fixups > rather than an overall design and structure. Maybe it's possible to > clean and simplify? > > I'd say if you resubmit the patch with all the extra research you did > in the commit message, that would help review. I don't have objections > anymore. There is a lot of history here. I'm tempted to suggest we remove the allarch inherit from packagegroup and add it to the recipes explicitly as it is all getting far too convoluted and I'd like to see things simplified, not complicated. I'd like to see the conditional code in allarch removed too FWIW if we can work out how to do it. Cheers, Richard
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py index 2d1d6ddeb75e..2bc57b8c343c 100644 --- a/meta/lib/oe/packagedata.py +++ b/meta/lib/oe/packagedata.py @@ -138,7 +138,7 @@ def get_package_mapping(pkg, basepkg, d, depversions=None): key = "PKG:%s" % pkg if key in data: - if bb.data.inherits_class('allarch', d) and bb.data.inherits_class('packagegroup', d) and pkg != data[key]: + if d.getVar("PACKAGE_ARCH") == "all" and bb.data.inherits_class('packagegroup', d) and pkg != data[key]: bb.error("An allarch packagegroup shouldn't depend on packages which are dynamically renamed (%s to %s)" % (pkg, data[key])) # Have to avoid undoing the write_extra_pkgs(global_variants...) if bb.data.inherits_class('allarch', d) and not d.getVar('MULTILIB_VARIANTS') \
allarch code is only triggered if PACKAGE_ARCH remains set to "all". This is not the case under some circumstances, like in the case of nativesdk class which overrides this variable. This error then breaks nativesdk package groups which depend on renamed packages yet aren't affected by allarch. Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com> --- meta/lib/oe/packagedata.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)