is sstate-cache really deterministic together with shlibs providers?

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

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?

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]