Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Bastien Nocera]

On Wed, 2020-02-26 at 15:51 +0100, Benjamin Berg wrote:
> On Wed, 2020-02-26 at 14:18 +0000, Simon McVittie wrote:
> > On Wed, 26 Feb 2020 at 14:39:06 +0100, Benjamin Berg wrote:
> > > I don't think that $XDG_CACHE_HOME is designed to be used
> > > directly by
> > > users. And if it is an application which generates those
> > > repositories,
> > > then again, it can just drop-in the appropriate configuration to
> > > prevent cleaning.
> > 
> > It isn't designed to be used directly by users, but it *is*
> > designed
> > to be used (or at least usable) by programs/scripts that those
> > users write
> > locally, which is quite a fine line.
> > 
> > I think going straight from "$XDG_CACHE_HOME is not systematically
> > cleaned"
> > to "$XDG_CACHE_HOME is cleaned unless you opt-out" breaks the
> > principle of
> > least astonishment for existing applications (and libraries) that
> > cache
> > things that are "expensive" to recreate.
> > 
> > A safer route to this would seem to be defaulting to *not* dropping
> > caches, and having applications whose caches are suitable for time-
> > based
> > cleaning opt-in to it by installing tmpfiles.d fragments.
> 
> Oh, I fully agree. Though I *do* want applications to explicitly ship
> an opt-out file if they do not want any cleaning ever. And
> threatening
> with automatic clean-up is probably a good idea, because otherwise no
> one will bother.

Why would they need to bother? There's nothing that requires this to be
regularly cleaned rather than cleaned when needed. You have absolutely
no way to know whether the cached data is resource-intensive to
recreate or not.

Leave it up to an app like Baobab to guide users to clean this _when
needed_, maybe have applications offer up more metadata about what they
cache, but the automatic cleaning is really not that interesting.

> So, I would still propose to write the requirement to ship a
> configuration file and the possibility of defaulting to clean after
> e.g. 30 days into the specification. That does not say anything about
> how long the grace period for such a change would be. And while I
> personally think we should flip the default eventually, we could
> still
> decide to never actually do so. Or leave the decision up to
> distributions and administrators.
> 
> > If the vast majority of $XDG_CACHE_HOME users end up opting-in to
> > cleanup,
> > then the default perhaps can be reconsidered later.
> > 
> > > > > Is it reasonable to standardise on the systemd tmpfiles.d
> > > > > format?
> > 
> > It seems as good a format as any: there's a specification that
> > other
> > projects can implement if they are running on non-Linux or don't
> > like
> > systemd for whatever reason, and reusing the design work that the
> > systemd
> > developers have put into that seems better than inventing a
> > parallel
> > "desktop tmpfiles" specification.
> > 
> > There is a shell-script reimplementation of most of tmpfiles.d
> > <https://github.com/OpenRC/opentmpfiles> but it doesn't currently
> > support
> > age-based cleaning or the --user mode.
> > 
> > I believe tmpfiles.d is intended to be idempotent, so if the
> > systemd
> > implementation and a parallel implementation end up both running
> > for
> > whatever reason, the practical effect is likely to be the same as
> > if
> > only one runs?
> 
> Nice. I had not seen opentmpfiles yet. The format does indeed seem
> simple enough so that at least the relevant subset should be easily
> implementable. And I suspect that the systemd implementation could
> also
> be split out and used elsewhere.
> 
> And yes, two cleaners should just result in a bit of excessive IO
> with
> no further negative impact.
> 
> Benjamin
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg