Re: ASSUME_PROVIDED += sqlite3-native doesn't work

[Detlef Vollmann <dv@vollmann.ch>]

On 01/06/14 10:46, Paul Eggleton wrote:
> Hi Detlef,
>
> On Sunday 05 January 2014 23:29:31 Detlef Vollmann wrote:
>> Specifying "ASSUME_PROVIDED += sqlite3-native" doesn't work,
>> as pseudo-native explicitely requires SQLite headers in
>> ${STAGING_DIR_NATIVE}.
>> Am I missing something or is this a bug?
>
> I don't think we'd consider this a bug. Basically, if you play around with
> ASSUME_PROVIDED and stuff breaks, you're on your own.
I agree that's my problem if my provided version doesn't have
the same functionality as the one built by OE (as e.g. pseudo and
fakeroot).
However, if ASSUME_PROVIDED doesn't work just because a package
that depends on it (here pseudo) hardcodes the location of
sqlite3 to be in the OE staging tree, then that's really annoying.

> In most cases it's safer
> to build our own versions of things rather than relying on them being
> available on the build host, particularly if you want things to continue to
> work on different host distributions.
That's true.  But my case is different: all our developers use the
same host distribution (otherwise a lot of other things will fail anyway).
Building the standard meta-toolchain produces a huge number of
packages, and it's hard to convince our admins that all those
packages really need to go into our local package repo.
So I'm trying to get down to a reasonable number of packages by using
the standard packages provided by the common host distribution.
This is, what ASSUME_PROVIDED is for.
But this is not possible if recipes are written in a way that
defeat the purpose of ASSUME_PROVIDED :-(

   Detlef