Re: [OE-core] why would ASSUME_PROVIDED recipes be built anyway?

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

On Thu, 2026-04-09 at 10:04 -0700, Robert P. J. Day via lists.openembedded.org wrote:
> On Wed, 8 Apr 2026, Richard Purdie wrote:
> 
> > On Wed, 2026-04-08 at 06:33 -0700, Robert P. J. Day via lists.openembedded.org wrote:
> > > 
> > >   puzzled by something i just noticed ... the documentation for
> > > "ASSUME_PROVIDED":"
> > > 
> > > https://docs.yoctoproject.org/ref-manual/variables.html#term-ASSUME_PROVIDED
> > > 
> > > clearly suggests that these represent recipes that would not be built
> > > as they are already on the host, the example given there is
> > > "git-native".
> > > 
> > >   however, in a walnascar-based build i just built, native recipes
> > > that were listed in ASSUME_PROVIDED were built anyway, even though
> > > they are clearly on my Debian 13 host, "git-native" among them. in
> > > fact, a number of recipes i checked appear to all have been built from
> > > scratch, despite being listed in ASSUME_PROVIDED.
> > > 
> > >   as a test, if i then tried to "cleanall" such a recipe, i got the
> > > perfectly reasonable:
> > > 
> > > 
> > > $ bitbake -c cleanall git-native
> > > ... snip ...
> > > WARNING: Explicit target "git-native" is in ASSUME_PROVIDED, ignoring
> > > 
> > > 
> > > is there some reason that something listed in ASSUME_PROVIDED will be
> > > fetched and built anyway? is it a version thing?
> > 
> > Some of the recipes have a PROVIDES for XXX-replacement-native and you
> > can build/depend on that.
> 
>   if i may, let's see how badly i'm going to misunderstand this.
> currently, in my build, if i dump the value of ASSUME_PROVIDED, i see
> a pile of native recipes, including (as defined in bitbake.conf)
> bzip2-native, diffstat-native, and patch-native, suggesting that if my
> build needs any of these recipes built natively, then *by default* it
> will try to use the ones already installed on the host.
> 
>   as an example, there's "quilt", which conveniently RDEPENDS on
> exactly those three native builds:
> 
>   .../quilt.inc:RDEPENDS:${PN}:class-native =
>     "diffstat-native patch-native bzip2-native"
> 
> so, simplistically, if i'm building quilt natively, none of those
> native recipes should need building -- building quilt will use the
> host versions.
> 
>   however, in the case of (for example) bzip2, we have that that
> recipe defines:
> 
> 
>   .../bzip2_1.0.8.bb:PROVIDES:append:class-native = " bzip2-replacement-native"
> 
> which means that some *other* recipe has the right (and here's where i
> might be misunderstanding) to state that, even if bzip2 is listed in
> ASSUME_PROVIDED and is available on the host, that other recipe can
> insist that it not use the host version, but must (for whatever
> reason) build the "replacement" version:
> 
>    .../cmake-native_4.3.1.bb:DEPENDS += "bzip2-replacement-native ..."
> 
> am i even *close* to understanding this correctly?
> 
> rday
> 
> p.s. so as i read it, all it takes is a single recipe being built that
> chooses to depend on a "replacement" recipe for that replacement
> recipe to be built and used.

Correct, but that replacement recipe will only be used by the recipes
which depend on the replacement, the others will still see the
HOSTTOOLS provided one. HOSTTOOLS and ASSUME_PROVIDED are generally
linked.

In the case of bzip2-replacement-native, what the recipe probably wants
is the bzip2 library, not the binary. Different replacements have
different reasons for being needed.

Cheers,

Richard