Re: is sstate-cache really deterministic together with shlibs providers?

[Phil Blundell <pb@pbcl.net>]

On Fri, 2013-06-07 at 21:20 +0200, Martin Jansa wrote:
> Imagine this process
> 
> foo.bb DEPENDS on libabc.bb to provide libabc.1.so
> 
> evil recipe bar.bb installs some binary crap in /opt/crap and because it's
> picky about libabc version it bundles own compy of libabc.so.1 and
> installs it to /opt/crap/lib/libabc.so.1
> 
> At the time of first build nobody notices libabc.1.so and foo, bar and
> libabc are happily populated to sysroot.
> 
> foo.bb is rebuilt because of some unrelated change, but this times it
> uses bar as shlibs provider for libabc.so.1

It sounds like the real bug here is that the shlibdeps code doesn't
issue a diagnostic when it encounters this kind of ambiguous situation.
It ought to be perfectly capable of figuring out that there are two
copies of libabc.so.1 at large which belong to different packages and,
absent additional guidance, it has no reliable way of knowing which one
of those is going to satisfy the DT_NEEDED in any random binary.

If shlibdeps stopped with an error in that situation, which arguably it
ought to, then the erroneous dependency would never get into sstate and
the scenario that you describe would not be able to happen.

p.