All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Oleksandr Hnatiuk" <ohnatiuk@cisco.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] package: disable renamed dependency error if allarch is overridden
Date: Tue, 13 May 2025 03:30:13 -0700	[thread overview]
Message-ID: <1013.1747132213222480212@lists.openembedded.org> (raw)
In-Reply-To: <CANNYZj96qMX_tZf-yu+jSac6R3+_BqjigTO=4kvkuSW=ja-G4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1433 bytes --]

  reply	other threads:[~2025-05-13 10:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09 21:19 [PATCH] package: disable renamed dependency error if allarch is overridden Oleksandr Hnatiuk
2025-05-12  9:02 ` [OE-core] " Alexander Kanavin
2025-05-12  9:31   ` Oleksandr Hnatiuk
2025-05-12  9:40     ` [OE-core] " Alexander Kanavin
2025-05-13 10:30       ` Oleksandr Hnatiuk [this message]
2025-05-14 13:16         ` Alexander Kanavin
2025-05-14 15:35           ` Oleksandr Hnatiuk
2025-05-15 12:55             ` [OE-core] " Alexander Kanavin
2025-05-19 10:13               ` Oleksandr Hnatiuk
2025-05-19 10:24                 ` Oleksandr Hnatiuk
2025-05-20 13:06                   ` [OE-core] " Alexander Kanavin
2025-05-20 13:23                     ` Richard Purdie
2025-07-10 15:02                     ` Oleksandr Hnatiuk
2025-07-11 17:42                       ` [OE-core] " Alexander Kanavin
2025-07-25 19:24                         ` Oleksandr Hnatiuk
2025-07-26 22:00                           ` [OE-core] " Alexander Kanavin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1013.1747132213222480212@lists.openembedded.org \
    --to=ohnatiuk@cisco.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.