Re: 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 <bluca@debian.org> writes:
> On Mon, 6 May 2024 at 15:42, Richard Lewis
> <richard.lewis.debian@googlemail.com> wrote:
>>
>> Luca Boccassi <bluca@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?
Reply to: