Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

Benjamin Berg <[email protected]> Wed, 26 Feb 2020 15:51:13 +0100
Newsgroups	gmane.linux.xdg.devel
Message-ID	<[email protected]>
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.

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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
signature.asc (application/pgp-signature, 833 B)