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]

[Luca Boccassi]

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?