From b3d49d5205555a3672ec323e3578b1f9acd74cd6 Mon Sep 17 00:00:00 2001 From: Joshua Watt Date: Thu, 28 Sep 2023 12:26:16 -0600 Subject: overview: Add note about non-reproducibility side effects Adds an additional note about some of the side effects that can occur if recipes are not reproducible and hash equivalence is enabled. (From yocto-docs rev: 968ac9807466df775f18fca050070170d3ed8585) Signed-off-by: Joshua Watt Reviewed-by: Michael Opdenacker Signed-off-by: Steve Sakoman --- documentation/overview-manual/concepts.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 668e002565..80d75dd7c3 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -1963,6 +1963,15 @@ task output from the Shared State cache. the stability of the task's output hash. Therefore, the effectiveness of Hash Equivalence strongly depends on it. + Recipes that are not reproducible may have undesired behavior if hash + equivalence is enabled, since the non-reproducible diverging output maybe be + remapped to an older sstate object in the cache by the server. If a recipe + is non-reproducible in trivial ways, such as different timestamps, this is + likely not a problem. However recipes that have more dramatic changes (such + as completely different file names) will likely outright fail since the + downstream sstate objects are not actually equivalent to what was just + built. + This applies to multiple scenarios: - A "trivial" change to a recipe that doesn't impact its generated output, -- cgit v1.2.3-54-g00ecf