Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Richard Lewis]

Luca Boccassi <bluca at debian.org> writes:

> On Mon, 6 May 2024 at 15:42, Richard Lewis
> <richard.lewis.debian at googlemail.com> wrote:
>>
>> Luca Boccassi <bluca at debian.org> writes:
>>
>> > Hence, I am not really looking for philosophical discussions or lists
>> > of personal preferences or hypotheticals, but for facts: what would
>> > break where, and how to fix it?
>>
>> cleaning /tmp or /var/tmp: users may lose files if they dont realise a
>>   directory tmp can be cleaned without a reboot. something in /var/tmp
>>   that's been in there for 35 days before an upgrade might be deleted
>>   before the user reads the NEWS.Debian email, meaning they have no
>>   chance to react). Maybe you could postpone the very first deletion
>>   until after the next reboot?
>>
>> using a tmpfs: is there a risk of losing unrelated data due to more
>>   frequent OOM killing random other programmes due to /tmp using all the
>>   memory?  is there a case to only use a tmpfs if the system has
>>   "enough" memory?
>
> Again, those are all hypotheticals, and one can construct similarly
> contrived thought exercises for most possible permutations of most
> configurations, and the answer is always the same: customize the
> configuration accordingly. Hence, not relevant right now.

> What is relevant is: which packages, if any, or which DSA-owned
> systems, if any, are actually affected and how?

Why do you think that the impact on users is less important than the
impact on debian packages?