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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg