diff mbox series

[RFC] overview: Add note about non-reproducibility side effects

Message ID 20230926160049.1537656-1-JPEWhacker@gmail.com
State New
Headers show
Series [RFC] overview: Add note about non-reproducibility side effects | expand

Commit Message

Joshua Watt Sept. 26, 2023, 4 p.m. UTC
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>
---
 documentation/overview-manual/concepts.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Ulrich Ölmann Sept. 26, 2023, 4:38 p.m. UTC | #1
Hi Joshua!

On Tue, Sep 26 2023 at 10:00 -0600, "Joshua Watt" <JPEWhacker@gmail.com> wrote:
> 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>
> ---
>  documentation/overview-manual/concepts.rst | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index af825a98c..0c2f148c8 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -1963,6 +1963,14 @@ 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-reprodible in trivial ways, such as different timestamps this is

s/non-reprodible/non-reproducible/

> +   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 not actually equivalent to what was just built.

s/objects not/objects are not/ ?

Best regards
Ulrich


> +
>  This applies to multiple scenarios:
>  
>  -  A "trivial" change to a recipe that doesn't impact its generated output,
Roland Hieber Sept. 28, 2023, 10:49 a.m. UTC | #2
On Tue, Sep 26, 2023 at 06:38:12PM +0200, Ulrich Ölmann wrote:
> Hi Joshua!
> 
> On Tue, Sep 26 2023 at 10:00 -0600, "Joshua Watt" <JPEWhacker@gmail.com> wrote:
> > 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>
> > ---
> >  documentation/overview-manual/concepts.rst | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> > index af825a98c..0c2f148c8 100644
> > --- a/documentation/overview-manual/concepts.rst
> > +++ b/documentation/overview-manual/concepts.rst
> > @@ -1963,6 +1963,14 @@ 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-reprodible in trivial ways, such as different timestamps this is
> 
> s/non-reprodible/non-reproducible/

I would also include an additional comma after "timestamps".

> > +   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 not actually equivalent to what was just built.
> 
> s/objects not/objects are not/ ?
> 
> Best regards
> Ulrich

 - Roland

> > +
> >  This applies to multiple scenarios:
> >  
> >  -  A "trivial" change to a recipe that doesn't impact its generated output,
> -- 
> Pengutronix e.K.                           | Ulrich Ölmann               |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#4300): https://lists.yoctoproject.org/g/docs/message/4300
> Mute This Topic: https://lists.yoctoproject.org/mt/101598940/5053951
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/docs/unsub [rhi@pengutronix.de]
> -=-=-=-=-=-=-=-=-=-=-=-
>
diff mbox series

Patch

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index af825a98c..0c2f148c8 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1963,6 +1963,14 @@  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-reprodible 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 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,