From 9f64aa4afce52c9b50499e6c0a4e56732f9a800a 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: 1ccc8eefe21bc432c903bb245bd0dab06e67cc14) Signed-off-by: Joshua Watt Reviewed-by: Michael Opdenacker Signed-off-by: Richard Purdie --- documentation/overview-manual/concepts.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'documentation/overview-manual/concepts.rst') diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index af825a98ce..4e3f6425a4 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