Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

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.

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?

    smcv