clone 355436 -1 severity 355436 whishlist retitle -1 bootclean.sh overwritten on upgrade thanks
On Mon, 06 Mar 2006, David Murn wrote: > time. As such, I edited my bootclean.sh script, and commented out all [...] > Part of this update, overwrote my modified script, then proceeded to This is a separate bug, I have cloned and retitled the report to track the two issues separately. > 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 AFAIK, Unix definition of /tmp is that it lasts only for the current session. This is why Solaris mounts it as (the equivalent of a) tmpfs, which is not disk-backed. /var/tmp is the one supposed to survive across reboots (in fact, I also have it as tmpfs in my machines). As for overwriting the script, if it was done *without* asking you first, then we have a grave bug somewhere. > Ive got 2 points to raise on this issue. Firstly, a new init script Raise one issue per bug report. I am fixing this manually, please direct comments about the optional cleaning to bug #355436, and about the overwritting of bootclean.sh to the new bug # that will be generated by the system when the "clone" command is processed. > 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 That's how it is supposed to happen, yes. > 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 As I said, /tmp is off-limits for persistent data. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
