Re: [OE-core] [PATCH v2 2/4] package_pkgdata: fix typo to stop calling undefined function

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sun, 2026-04-12 at 16:18 +0200, Adam Blank wrote:
> I've dug some more, as I couldn't come to terms with it ;-)

I'm certainly a bit concerned with what you found and have been wanting
to try and find time to understand what is going on. It would seem we
simply must not be calling that code path?

> I've got a fix and a reasoning behind it: when the typo is fixed, a
> new callable function is identified and treated as a dependency of
> 'do_package'. This in turn pulls in its dependency on
> 'PACKAGE_EXTRA_ARCHS' and the test must fail.
> The fix is simply about making sure, that
> 'package_populate_pkgdata_dir' has 'PACKAGE_EXTRA_ARCHS' and a few
> other variables in its 'vardepsexclude'.

That is a good find and would certainly explain the error.

> What bothered me was something else though. I could clearly see, how
> this part of code in 'package.bbclass' was based on
> 'staging.bbclass'. There is an identical chain of dependencies:
> - do_prepare_recipe_sysroot -> extend_recipe_sysroot -
> > staging_populate_sysroot_dir (referencing 'PACKAGE_EXTRA_ARCHS')
> - do_package -> package_prepare_pkgdata -
> > package_populate_pkgdata_dir (referencing 'PACKAGE_EXTRA_ARCHS')

That would bother me too and is a very good question.

> I couldn't believe that somehow 'do_package' had this issue, but
> 'do_prepare_recipe_sysroot' didn't (for no apparent reason). After an
> extremely long chase, I found 'extend_recipe_sysroot' in
> 'BB_BASEHASH_IGNORE_VARS'... Since this was more unexpected to me
> than the Spanish Inquisition, and has been there since 2017, I'd like
> to ask:
> 
> - Is it truly justified for 'extend_recipe_sysroot' to have this sort
> of globally unique, special treatment?
> - Wouldn't it be better for it to be handled using the same mechanism
> that are applied to other functions? 

Those are good questions. I suspect this:

* was done to make things a little easier on rebuilds if/as/when 
  that code changes
* was by 'design' in that it was anticipated that 
  extend_recipe_sysroot would be called from more places than it 
  may have ended up being called from
* may have predated the exclusion mechanisms being reliable

I'd not be against using more exclusions and moving it out of
BB_BASEHASH_IGNORE_VARS but we'd have to be very careful about the
potential new dependency chains and carefully audit them.

Cheers,

Richard