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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
