Re: Dependency resolving ignores changed sstate-cache?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2011-12-13 at 10:30 +0100, Samuel Stirtzel wrote:
> it seems that I accidentally deleted fbset from my
> .../tmp-eglibc/work/... dir while cleaning out old builds for another
> recipe.
> For some reason I had a r0 directory from the past of the recipe which
> is now r1.
> So I deleted it manually and fbset too, but I didn't notice.
> 
> Thereafter I built an image that has been already built before,
> but it had some IMAGE_INSTALL changes.
> Everything was alright until opkg encountered the following error:
> | Collected errors:
> |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies for qt4-x11-free:
> |  *    fbset *
> |  * opkg_install_cmd: Cannot install package qt4-x11-free.
> 
> Of course it could not find fbset, as it was deleted previously,
> so I did a "bitbake -ccleansstate fbset" but the error still occurred.
> 
> 
> This leads me to the conclusion, that the sstate-cache change was not
> noticed by bitbake?
> Or is there higher cache instance file that makes bitbake believe that
> fbset was built?
> 
> After I built fbset with bitbake manually everything went back to normal,
> so there is no problem just confusion :)
> 
> 
> 
> For the reason of understanding it, is there any recent documentation
> about the dependency caching of bitbake?

Usually the above is a sign of a dependency bitbake has not been aware
of. Could you see which .ipk has the dependency on fbset?

Its likely some recipe doesn't have fbset in DEPENDS but is somehow
depending on it if it happened to be built before that recipe and was
present in the sysroot. Usually this happens with libraries so I'm a
little puzzled why it would happen with a binary unless there is a lib
in that package too.

Cheers,

Richard