Richard Purdie 02bc1b422b bitbake: hashserv: Improve behaviour for better determinism/sstate reuse ... We have a choice of policy with hashequivalence - whether to reduce sstate duplication in the sstate feed to a minimum or have maximal sstate reuse from the user's perspective. The challenge is that non-matching outhashes are generated due to determinism issues, or due to differences in host gcc version, architecture and so on and the question is how to reconcile then. The approach before this patch is that any new match is added and matches can update. This has the side effect that a queried value from the server can change due to the replacement and you may not always get the same value from the server. With the client side caching bitbake has, this can be suboptimal and when using the autobuilder sstate feed, it results in poor artefact reuse. This patch switches to the other possible behaviour, once a hash is assigned, it doesn't change. This means some sstate artefacts may be duplicated but dependency chains aren't invalidated which I suspect may give better overall performance. Update the tests to match the new behaviour. (Bitbake rev: 20d6ac753efa364349100cdc863e5eabec8e5b78) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>		2021-10-11 11:00:06 +01:00
..
__init__.py	bitbake: hashserv: Fix diverging report race condition	2021-10-11 11:00:06 +01:00
client.py	bitbake: hashserv: Fix diverging report race condition	2021-10-11 11:00:06 +01:00
server.py	bitbake: hashserv: Improve behaviour for better determinism/sstate reuse	2021-10-11 11:00:06 +01:00
tests.py	bitbake: hashserv: Improve behaviour for better determinism/sstate reuse	2021-10-11 11:00:06 +01:00