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

["Robert P. J. Day" <rpjday@crashcourse.ca>]

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

On Thu, 9 Apr 2026, Richard Purdie wrote:

> 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.

  this is definitely useful information to know but it might be a bit
much to try to sneak into a reference entry. an alternative might be
to add another subsection to the already 42 subsections in the dev
tasks manual:

  https://docs.yoctoproject.org/dev-manual/index.html#

which explains the rationale of, and inter-relationship between, the
variables ASSUME_PROVIDED, HOSTTOOLS and HOSTTOOLS_NONFATAL if people
think it's worth it.

rday