Re: [RFC] One shared state reuse solution

[Mark Hatle <mark.hatle@windriver.com>]

On 3/30/12 5:09 PM, Chris Larson wrote:
> On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle<mark.hatle@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).

It would be nice if the host libc was the only dependency.  ;)

Have you run any type of scan on the host dependencies to see where we actually 
sit?  I know a while back I ran a scan and was surprised at how few host 
dependencies there was in a fairly standard oe-core build.

--Mark

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