Luca Boccassi <bl...@debian.org> writes: > On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter <b...@debian.org> wrote: >> >> > We have two separate issues here: >> >> > a/ /tmp-on-tmpfs >> > b/ time based clean-up of /tmp and /var/tmp >> >> > I think it makes sense to discuss/handle those separately. >> >> Agreed. >> >> I also don't see any issue with a/, at worst people will be annoyed >> with it for some reason and can then change it back. >> >> > Regarding b/: ... >> >> > The tmpfiles rule tmp.conf as shipped by systemd upstream ... >> > Files that are older then 10 days or 30 days are automatically cleaned up. >> >> This seems like a rather dangerous thing to spring on people. >> >> First of all, time can be pretty fluid on user machines. > > Then upon reading the release notes, on such a machine, one can simply do: > > touch /etc/tmpfiles.d/tmp.conf > > And they get no automated cleanups. This stuff is designed to be > trivially overridable, both by end-users and image builders. What I am > looking for is, what packages need bugs/MRs filed to deal with this > change, if any.
Isn't this change (as presented) effectively about masking bugs? We've had people suggesting that implementing this will surprise them and disrupt their existing use of /var/tmp as scratch storage, and I've got a lot of sympathy with that, so I'm guessing that the people that are expected to benefit from this are not those that remember systems where the main distinction between /tmp and /var/tmp was that /tmp got emptied at boot time, whereas /var/tmp did not. That makes me assume that those that would be most likely benefit from such a change will mainly be users that are never going to type "/tmp" (with or without a preceding "/var"), and are therefore not going to have any idea what is being deleting for them, but will be happy never to get their disk filled. This makes me wonder what it is that we're expecting to need to delete. Is this a symptom of sloppy applications that fail to clear up the debris they create in /var/tmp? If so, is that not a bug in that application? I'd suggest that rather than clearing up after the sloppy behaviour of buggy applications, we instead leave it visible, in the hope that it can then be fixed. Of course, that's obviously not worked in some (many?) cases, so where we know of problematic packages, could we not add per-package tmpfiles.d files that name the specific paths that those packages are known to litter the system with, with appropriate deletion timeouts chosen by the Maintainer? That ought to achieve the benefit you're looking for, without hiding symptoms of future problems with other packages, and without inconveniencing anyone that's using /var/tmp as scratch space. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
signature.asc
Description: PGP signature
