[OE-core] is sstate-cache really deterministic together with shlibs providers?

[Richard Purdie]

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
> 
> foo does not work in runtime, because it cannot find libabc.so.1 hidden
> in /opt/crap/lib.
> 
> bar.bb is "fixed" by adding EXCLUDE_FROM_SHLIBS to prevent further
> polluting of shlibs providers, but damage is already done.
> 
> foo doesn't have any dependency on bar (DEPENDS/RDEPENDS) because bar.bb
> is just unrelated binary crap which just happens to bundle libabc.so.1
> too (so foo checksum does not include bar checksum)
> 
> Now the tricky part:
> 1) fixing local build is easy
>    bitbake -c cleansstate `grep ' bar' buildhistory/images/machine/eglibc/image-with-foo/depends.dot | sed 's/ -> .*//g' | xargs`
> 
> but sstate checksums are identical with bar or libabc in package
> "Depends:" field, so how to cleanup SSTATE_MIRROR and sstate archives
> already distributed to every local builder?
> 
> I could bump PR in libabc, but with PR bumps and PRINC going away I
> really need to know how to solve such issues in future. Should we fix
> do_package to filter shlibs providers to include only recipes which 
> are in (R)DEPENDS/RRECOMMENDS/RSUGGESTS?

PR bumps can still happen for corner cases like this, the intent is just
to rely on the system for the 99.9% of cases which it does cover much
more accurately than a human.

We should perhaps limit shlibs to the default linker search paths?

Wouldn't there be a warning if two things provide the same shlibs or
does that assume the shlibs versioning sorts itself out?

Cheers,

Richard