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 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
