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>

1 files changed, 1 insertions, 1 deletions

diff --git a/bitbake/lib/hashserv/server.py b/bitbake/lib/hashserv/server.py
index ef8227d430..d40a2ab8f8 100644
--- a/bitbake/lib/hashserv/server.py
+++ b/bitbake/lib/hashserv/server.py
@@ -413,7 +413,7 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
                     # A matching output hash was found. Set our taskhash to the
                     # same unihash since they are equivalent
                     unihash = row['unihash']
-                    resolve = Resolve.REPLACE
+                    resolve = Resolve.IGNORE
                 else:
                     # No matching output hash was found. This is probably the
                     # first outhash to be added.