[OE-core] ASSUME_PROVIDED versus SANITY_REQUIRED_UTILITIES versus "The Build Host Packages"

[Patrick Ohly]

On Mon, 2016-11-28 at 12:04 +0000, Richard Purdie wrote:
> On Mon, 2016-11-28 at 06:20 -0500, Robert P. J. Day wrote:
> >   a bit confused by what i'm seeing in a recent
> > qemuppc/core-image-minimal build on my fedora system regarding which
> > native packages are built, despite what's in bitbake.conf (using
> > current poky layer checkout).
> > 
> >   first, here's a snippet from bitbake.conf:
> > 
> >   ASSUME_PROVIDED = "\
> >     bzip2-native \          <---
> >     chrpath-native \
> >     file-native \           <---
> >     findutils-native \
> >     git-native \
> >     grep-native \
> >     diffstat-native \
> >     ... snip ...
> > 
> > suggesting that (among other things) bzip2-native and file-native
> > shouldn't be built -- it's the developer's responsibility to install
> > them, yes? but if i peek under tmp/work/x86_64-linux, i can see:
> 
> There are two ways "file-native" can be used in a build. It can be used
> as the host provided "file" command and it is also needed by the file
> recipe to build file for the target.

I recently ran into a third usage of "file-native": swupd-server links
against libmagic from file and therefore has a DEPENDS = "file". But
building swupd-server-native didn't actually build file because of
ASSUME_PROVIDED and because I hadn't installed libmagic-dev on my build
host, the build was failing.

Is there a way to declare that ASSUME_PROVIDED does not apply to this
case? It sounds like there is a way (based on your comments about
building file-native when building file and the libbz2-devel example),
but it did not become clear to me how that works in practice.

Or is it just a case of educating the developer that libmagic-dev needs
to be installed on the build host in addition to the file command?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.