Mailinglist Archive: opensuse-factory (435 mails)

< Previous Next >
Re: [opensuse-factory] Proposal: /tmp as tmpfs
Hi,

On 7/10/20 8:10 AM, Richard Brown wrote:
On Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@xxxxxxx>
<snip>
I would vehemently oppose, as we have 3rd-party applications that
write to (NOT configurable) /tmp and expect it to last there for a
certain time (even after a reboot).

To workaround of that, I have created several symbolic links on /tmp
to /data/tmp (or /opt/app/tmp or whatever) and I would be very
unpleased to see all those symlinks disappear on a reboot. That would
mean I have to write service files that fire up immediately after
/tmp
comes up and recreates those symlinks before the application wants to
start.

I really like to keep my /tmp's as clean as possible, but sometimes
it
is not under our control :(

FWIW I never had to do anything like that on /usr/tmp

Those applications are in serious breach of both the FHS
recommendations and POSIX requirements.

I am not opposed to the change and recognize that applications that do
not conform to standards are difficult to deal with. However, lecturing
the users of those applications about the problem is not really helpful.


I would imagine they have a vested interest in fixing that problem.


Why? Making the assumption that these are proprietary applications the
question would arise how many new customers a modified application that
adheres to the standard would attract? A feature in an application
description "now FHS and POSIX compliant for temporary file handling"
doesn't sound very sexy to me and I would hap hazard a guess that it
will not have a large influence on purchasing decisions. Bottom line a
change of an application that does not provide a tangible benefit to
attract new customers is pure cost to an ISV and that is hard to swallow.

Again, it comes down to making the transition obvious to handle, and for
users to disable the new behavior in an easy way when necessary.

Later,
Robert


--
Robert Schweikert MAY THE SOURCE BE WITH YOU
Distinguished Engineer LINUX
Technical Team Lead Public Cloud
rjschwei@xxxxxxxx
IRC: robjo

< Previous Next >
This Thread