Re: [PATCH 1/1] sstate.bbclass: update the timestamps after install

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2014-09-04 at 16:49 +0800, Robert Yang wrote:
> 
> On 09/04/2014 04:27 PM, Richard Purdie wrote:
> > On Thu, 2014-09-04 at 00:05 -0700, Robert Yang wrote:
> >> Update the sstate file's timestamps after it is installed, it will be
> >> very useful for removing the old sstate file, especially, it's not easy
> >> to remove when use the shared SSTATE_DIR, we can easily remove them with
> >> this change, for example:
> >>
> >> $ find state-cache -type f -ctime +10 -exec rm -f {} \;
> >>
> >> Will remove the sstate file which isn't used by recent 10 days.
> >>
> >> We can use the -atime, but it is not always available, for example,
> >> when mounted with "-o noatime".
> >>
> >> The touch is a very light weight action, and the
> >> scripts/sstate-cache-management.sh also requires this.
> >>
> >> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> >> ---
> >>   meta/classes/sstate.bbclass |    1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> >> index ead829e..885912d 100644
> >> --- a/meta/classes/sstate.bbclass
> >> +++ b/meta/classes/sstate.bbclass
> >> @@ -618,6 +618,7 @@ sstate_unpack_package () {
> >>   	mkdir -p ${SSTATE_INSTDIR}
> >>   	cd ${SSTATE_INSTDIR}
> >>   	tar -xmvzf ${SSTATE_PKG}
> >> +	touch --no-dereference ${SSTATE_PKG}
> >>   }
> >>
> >>   BB_HASHCHECK_FUNCTION = "sstate_checkhashes"
> >
> > At the very least we need to consider read only files here...
> 
> Hello, did you mean the SSTATE_MIRRORS ? I thought that I had
> considered it since I used the "touch --no-dereference",
> make a clear check is reasonable if I understand correctly,
> so updated the code in the repo: (The --no-dereference is not
> need any more since the "test -w" follows symlink).

We need the --no-dereferece but this could also be a readonly directory
or set of readonly files (think an ISO shipped with WR Linux or locked
sstate cache).

Cheers,

Richard