why would ASSUME_PROVIDED recipes be built anyway?

why would ASSUME_PROVIDED recipes be built anyway?

[Robert P. J. Day]

  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?

rday

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

[Richard Purdie]

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.

Cheers,

Richard

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

[Robert P. J. Day]

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

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.

  sounds like something that should be in the docs, just to avoid my
level of confusion. :-)

rday

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

[Richard Purdie]

On Wed, 2026-04-08 at 14:52 -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.
> 
>   sounds like something that should be in the docs, just to avoid my
> level of confusion. :-)

I'm sure you could work out a suitable patch! ;-)

Cheers,

Richard

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

[Robert P. J. Day]

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

On Wed, 8 Apr 2026, Richard Purdie wrote:

> On Wed, 2026-04-08 at 14:52 -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.
> >
> >   sounds like something that should be in the docs, just to avoid my
> > level of confusion. :-)
>
> I'm sure you could work out a suitable patch! ;-)

  already working on it. :-)

rday

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

[Robert P. J. Day]

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

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.

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

[Richard Purdie]

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

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

[Robert P. J. Day]

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

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

[Antonin Godard]

Hi,

On Fri Apr 10, 2026 at 12:49 PM CEST, Robert P. J. Day wrote:
[...]
>   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#

It's not really a development task.

How about a section in https://docs.yoctoproject.org/overview-manual/concepts.html?

Antonin