On 26/02/2020 14:30, Benjamin Berg wrote: > On Wed, 2020-02-26 at 14:22 +0100, Bastien Nocera wrote: >> On Wed, 2020-02-26 at 13:45 +0100, Benjamin Berg wrote: >>> Now, systemd-tempfiles can already clean up everything except for the >>> trash. And considering that $XDG_CACHE_HOME is non-essential by >>> definition, I think it might be sane to use systemd-tempfiles not only >>> to clean the thumbnails but the entirety of $XDG_CACHE_HOME in the >>> future. >> >> It's not "non-essential", it's a cache, which can be regenerated, but >> it might be utterly costly to do so. Eg. there are 10 gigs of "cached" >> evolution mails in my ~/.cache, 5 gigs of jhbuild builddirs. >> >> Nuking it is a last ditch scenario. You'd avoid backing it up on space >> constrained storage, but you'd want to avoid having to regenerate that >> cache in most cases. > > I am *not* proposing to nuke these directories. I am proposing to nuke > them by default, and ask applications like evolution, jhbuild and > others to ship their own configuration. >
I’m not sure a destructive by default behavior is a good thing even on a cache directories. I’m pretty sure this will lead to a lost of data. > This matches the behaviour of /tmp and /var/tmp on systemd managed > systems. In the simplest case, all evolution needs to do is ship a one > line file with: > > x %C/evolution > > This file can even be installed to the users $XDG_CONFIG_DIR for > applications that might not be able to do it globally. > Not all GNU/linux comes with systemd. Protocol and specification over tools/implementation specific. If it come restrictive it’s not good. Exept for security stuff and even in this case it’s not always a good choice. (for ie : 2fa when only choice is a phone) >> <snip> >>> Is it reasonable to standardise on the systemd tmpfiles.d format? >>> Is it OK to clean $XDG_CACHE_HOME after a fixed time period by >>> default? >> >> I'm guessing that's a no. >> >> As for thumbnails, you'd probably get away with checking whether atime >> is actually set on that mount and cleaning up the ones that haven't >> been used. > > Benjamin > > > _______________________________________________ > xdg mailing list > xdg@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/xdg >
0x053A41EF03878A98.asc
Description: application/pgp-keys
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg