Re: [PATCH v2 2/2] ref-manual: tasks: do_cleansstate: recommend using '-f' instead for a shared sstate

[Luca Ceresoli <luca.ceresoli@bootlin.com>]

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

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com