
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@suse.cz> <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@suse.com IRC: robjo