All of lore.kernel.org
 help / color / mirror / Atom feed
From: michael.opdenacker@bootlin.com
To: docs@lists.yoctoproject.org
Cc: Michael Opdenacker <michael.opdenacker@bootlin.com>,
	Joshua Watt <JPEWhacker@gmail.com>
Subject: [mickledore][PATCH 3/4] overview: Add note about non-reproducibility side effects
Date: Wed, 11 Oct 2023 15:37:19 +0200	[thread overview]
Message-ID: <20231011133720.78265-3-michael.opdenacker@bootlin.com> (raw)
In-Reply-To: <20231011133720.78265-1-michael.opdenacker@bootlin.com>

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

From: Joshua Watt <JPEWhacker@gmail.com>

Adds an additional note about some of the side effects that can occur if
recipes are not reproducible and hash equivalence is enabled.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 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,
-- 
2.34.1



  parent reply	other threads:[~2023-10-11 13:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11 13:37 [mickledore][PATCH 1/4] ref-manual: releases.svg: Scarthgap is now version 5.0 michael.opdenacker
2023-10-11 13:37 ` [mickledore][PATCH 2/4] dev-manual: fix testimage usage instructions michael.opdenacker
2023-10-11 13:37 ` michael.opdenacker [this message]
2023-10-11 13:37 ` [mickledore][PATCH 4/4] migration-guides: add release notes for 4.0.13 michael.opdenacker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231011133720.78265-3-michael.opdenacker@bootlin.com \
    --to=michael.opdenacker@bootlin.com \
    --cc=JPEWhacker@gmail.com \
    --cc=docs@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.