| Message ID | 20240227-clean-tasks-notes-v2-2-35fb627e9ca0@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | Discourage using do_cleansstate and do_cleanall | expand |
Hi Luca, On 2/27/24 11:59, Luca Ceresoli wrote: > do_cleansstat can produce build errors when using a shared sstate cache. > > Add a note to clearly discourage, provide a safe alternative (bitbake -f), > and the rationale. > > Proposed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> > Link: https://lore.kernel.org/yocto-docs/20240219155513.76738-1-luca.ceresoli@bootlin.com/T/#m5529687ecb0f9ec2dacddcb6ff58e2df73af9cde > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> > --- > documentation/ref-manual/tasks.rst | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst > index ebaa03dc7613..9f130bb4e0c9 100644 > --- a/documentation/ref-manual/tasks.rst > +++ b/documentation/ref-manual/tasks.rst > @@ -513,6 +513,18 @@ When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build syste > no longer uses any sstate. Consequently, building the recipe from > scratch is guaranteed. > > +.. note:: > + > + Using :ref:`ref-tasks-cleansstate` with a shared sstate directory is not I would add a :term:`SSTATE_DIR` here to highlight what we're talking about. > + recommended because it could trigger an error during the build of a s/of/from/ ? > + separate bitbake instance. This is because the builds check sstate "up > + front" but download the files later, so it if is deleted in the > + meantime, it will cause an error but not a total failure as it will > + rebuild it. > + Is bitbake actually safe from corruption? i.e. what happens if the file gets removed while it's being currently downloaded by another bitbake instance? Also, I would really recommend adding a similar warning in the cleanall target. We would have a disclaimer on the use of shared download dir but not on a shared sstate cache. One way to do it could be to link from the cleanall target to the cleansstate target telling the user to check other limitations that apply to both targets. Cheers, Quentin
Hi Quentin, On Tue, 27 Feb 2024 12:30:48 +0100 Quentin Schulz <quentin.schulz@theobroma-systems.com> wrote: > Hi Luca, > > On 2/27/24 11:59, Luca Ceresoli wrote: > > do_cleansstat can produce build errors when using a shared sstate cache. > > > > Add a note to clearly discourage, provide a safe alternative (bitbake -f), > > and the rationale. > > > > Proposed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> > > Link: https://lore.kernel.org/yocto-docs/20240219155513.76738-1-luca.ceresoli@bootlin.com/T/#m5529687ecb0f9ec2dacddcb6ff58e2df73af9cde > > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> > > --- > > documentation/ref-manual/tasks.rst | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > > > diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst > > index ebaa03dc7613..9f130bb4e0c9 100644 > > --- a/documentation/ref-manual/tasks.rst > > +++ b/documentation/ref-manual/tasks.rst > > @@ -513,6 +513,18 @@ When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build syste > > no longer uses any sstate. Consequently, building the recipe from > > scratch is guaranteed. > > > > +.. note:: > > + > > + Using :ref:`ref-tasks-cleansstate` with a shared sstate directory is not > > I would add a :term:`SSTATE_DIR` here to highlight what we're talking about. Sure. > > > + recommended because it could trigger an error during the build of a > > s/of/from/ ? > > > + separate bitbake instance. This is because the builds check sstate "up > > + front" but download the files later, so it if is deleted in the > > + meantime, it will cause an error but not a total failure as it will > > + rebuild it. > > + > > Is bitbake actually safe from corruption? i.e. what happens if the file > gets removed while it's being currently downloaded by another bitbake > instance? I'm happily leaving this question to Richard. :) > Also, I would really recommend adding a similar warning in the cleanall > target. We would have a disclaimer on the use of shared download dir but > not on a shared sstate cache. One way to do it could be to link from the > cleanall target to the cleansstate target telling the user to check > other limitations that apply to both targets. The first line in the do_cleanall sections points to do_cleansstate, and in patch 1/2 we have even stronger reasons to not use do_cleanall. I think that's enough. Luca
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst index ebaa03dc7613..9f130bb4e0c9 100644 --- a/documentation/ref-manual/tasks.rst +++ b/documentation/ref-manual/tasks.rst @@ -513,6 +513,18 @@ When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build syste no longer uses any sstate. Consequently, building the recipe from scratch is guaranteed. +.. note:: + + Using :ref:`ref-tasks-cleansstate` with a shared sstate directory is not + recommended because it could trigger an error during the build of a + separate bitbake instance. This is because the builds check sstate "up + front" but download the files later, so it if is deleted in the + meantime, it will cause an error but not a total failure as it will + rebuild it. + + The reliable and preferred way to force a new build is to use ``bitbake + -f`` instead. + .. note:: The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate
do_cleansstat can produce build errors when using a shared sstate cache. Add a note to clearly discourage, provide a safe alternative (bitbake -f), and the rationale. Proposed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/yocto-docs/20240219155513.76738-1-luca.ceresoli@bootlin.com/T/#m5529687ecb0f9ec2dacddcb6ff58e2df73af9cde Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> --- documentation/ref-manual/tasks.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+)