CaROS/poky
3
1
Fork 0
mirror of https://git.yoctoproject.org/git/poky synced 2026-01-04 16:10:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

overview: Add note about non-reproducibility side effects

Browse Source 
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 <JPEWhacker@gmail.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This commit is contained in:
Joshua Watt 2023-09-28 12:26:16 -06:00 committed by Steve Sakoman
parent fbf88236e3
commit a721e0f85b
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
documentation/overview-manual/concepts.rst
View File

@ -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,