| Message ID | 20230926160049.1537656-1-JPEWhacker@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] overview: Add note about non-reproducibility side effects | expand |
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,
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 --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,
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(+)