[Pkg-sysvinit-devel] Bug#355436: Cleaning /tmp should be optional

[David Murn]

Package: initscripts
Version: 2.86.ds1-12
Severity: important

Like many others Im sure, I use my /tmp partition for storing files that I  
dont necessarily want to keep forever, but may for a short period of  
time.  As such, I edited my bootclean.sh script, and commented out all  
code referring to /tmp.  For maybe 6 months this system worked well, until  
I recently performed a dist-upgrade and the initscripts package was  
updated.

Part of this update, overwrote my modified script, then proceeded to  
delete approximately 100mb of debs and other files that I had backed up  
 from another server I was upgrading.  In all, I lost approximately 200mb  
of data.  Now, while I can understand in a pristine environment, for users  
who dont understand what they're doing, keeping /tmp clean, is a good  
idea, but for advanced users, generally we know what we're doing and  
dislike things happening that we dont know about.

Ive got 2 points to raise on this issue.  Firstly, a new init script  
should never be installed without first checking if the previous script  
has been modified.  Apt did try to modify several scripts (most of which I  
disallowed as I have made major modifications to them), but I received no  
warning at all about bootclean being modified.  Not only did apt trash all  
my data in /tmp, but it also trashed all changes I made to the script to  
stop it trashing /tmp in the first place.

As a second thought to this, it would be nice if as part of the install  
process, if the user was asked if they want the script to blindly delete  
files on every startup.  Im sure Im not the only person who downloads  
files temporarily (especially large debian archives) to /tmp.  Maybe this  
could be added as part of the debconf system for advanced users.

While I can understand the reasoning behind it, the mere fact that a  
debian script can blindly delete an entire directory is incredibly scary  
to me, as a user.  Although it meets the criteria for a 'grave' bug  
(causing user data loss), I have only given it a tag of 'important', as it  
is only one part of the package which is troublesome.

David