ASSUME_PROVIDED += sqlite3-native doesn't work

ASSUME_PROVIDED += sqlite3-native doesn't work

[Detlef Vollmann]

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?

   Detlef

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

[Paul Eggleton]

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

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Detlef Vollmann]

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

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

[Richard Purdie]

On Mon, 2014-01-06 at 11:57 +0100, Detlef Vollmann wrote:
> 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 :-(

In an ideal world the recipe wouldn't do that I agree. In reality there
was probably some need to do it. We might be able to get away with a
pkgconfig call instead which would then better autoselect as you're
after it to. Feel free to send patches but they mustn't break the
default use case.

I would suggest that using ASSUME_PROVIDED like this is not really the
best way to use the system. You'd be much better off using something
like a sstate cache for the native recipes you want to provide. You
could even use the "locked sstate" patches I posted recently on the
OE-Core list to lock those to specific sstate checksums.

You could also use the buildtools tarball to install a set of natives
like pseudo which would be much more compatible with the system than
taking them from the host. The tarball is relocatable and can be
installed into your homedir so you don't have to involve sysadmins to
make it work.

We have done a lot of work trying to optimise out -native dependencies
where we can, and trying to optimise the process so they ones we need
first have as minimal dependencies as we can make them.

Cheers,

Richard