[OE-core] [RFC] One shared state reuse solution

[Chris Larson]

On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
>
> We've worked on a similar problem in the past.  In specific cases we've
> added a checksum of the host's glibc to the mix.  The problem we were
> solving was in glibc uprevs during the RHEL 4 world.. new APIs would arrive
> and things would break -- or workaround would break.
>
> Have you considered adding that to the mix in an attempt to help determine
> compatible host distributions?

It's been discussed in the past, but the problem is, as far as I know,
glibc isn't the only build host dependency we have. It's the most
visible, since glibc versioned symbols are the first place one
generally sees this sort of failure, but I think the safe bet is to
operate based upon the distro name/version, to avoid any potential
other compatibility issues with other host libraries that get linked
against. It'd be nice to ensure that glibc is the only dependency, at
which point that sort of approach would be more reliable, but I don't
think we're there yet (please correct me if I'm wrong here).

> I do like the idea of directory based sstate cache.  It can more easily
> identify what the components belong to.  (I wouldn't mind some type of
> hierarchy for the target stuff as well, but so far I'm not sure exactly it
> would look like or trigger off of.)
>
> However, shy of directory based.. adjusting the generated checksum in some
> way should be enough -- the downside is how do you detect compatible hosts
> or not..  You may have to generate multiple checksums and look for best
> matches, which I suspect is also new code.

What we had before this was just injection of the lsb_release
identifier/release into the native/cross signatures via vardeps, but
as you say, dealing with compatible hosts is non-trivial. I'm
certainly open to that sort of approach, but as you say, I think
there's other value to this approach, and seems a bit less confusing
:) Thanks for the comments, it's certainly a non-trivial problem to
solve.
-- 
Christopher Larson