From a721e0f85be99c686ac8c10a34a839fd593ddeae 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: aaf3e97c78e235bf3042c79ecdcf0b7c1a68ca8f) 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(+) (limited to 'documentation') diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 7ad21e0d7d..76e02eafff 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -2004,6 +2004,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