From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5107C3ABC9 for ; Tue, 13 May 2025 10:30:21 +0000 (UTC) Subject: Re: [PATCH] package: disable renamed dependency error if allarch is overridden To: openembedded-core@lists.openembedded.org From: "Oleksandr Hnatiuk" X-Originating-Location: London, England, GB (64.103.40.18) X-Originating-Platform: Linux Firefox 137 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 13 May 2025 03:30:13 -0700 References: In-Reply-To: Message-ID: <1013.1747132213222480212@lists.openembedded.org> Content-Type: multipart/alternative; boundary="tdbAizH7qH1XYXNoNqgR" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 13 May 2025 10:30:21 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/216409 --tdbAizH7qH1XYXNoNqgR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 packag= e renaming * packagegroup.bbclass unconditionally (because of immediate expansion) inh= erits allarch.bbclass * nativesdk.bbclass overrides PACKAGE_ARCH with correct value, preventing c= ode in allarch.bbclass from executing (because allarch.bbclass tests this v= ariable before doing anything) * bitbake raises an allarch-specific error by testing whether allarch was e= ver 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 i= ncorrect. allarch.bbclass is unique in that we cannot test if it is really used witho= ut checking the value of PACKAGE_ARCH. If we simply check via bb.data.inherits_class, we get false positives (agai= n, see step 4). Thus, it is incorrect to issue an error for packagegroups that inherit alla= rch 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. --tdbAizH7qH1XYXNoNqgR Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I will have to check why such packages are included.

However, consider the following. Here are all the parts of this = issue:
  1. a packagegroup explicitly inherits packagegroup and nativesdk classes
  2. same packagegroup depends on a package which is subject to dynamic pack= age renaming
  3. packagegroup.bbclass unconditionally (because of immediate expansion) i= nherits allarch.bbclass
  4. nativesdk.bbclass overrides PACKAGE_ARCH with correct value, preventing= code in allarch.bbclass from executing (because allarch.bbclass tests this= variable before doing anything)
  5. 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 se= ems incorrect.
allarch.bbclass is unique in that we cannot test if it = is really used without checking the value of PACKAGE_ARCH.
If we simpl= y 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 in= herit allarch without also verifying that they are actually allarch via PAC= KAGE_ARCH.
Without this extra check, the error is produced for package= groups for which code in allarch.bbclass was never and will never be execut= ed.
--tdbAizH7qH1XYXNoNqgR--