On 17-Apr-99, 22:20 (CDT), "Brian E. Ermovick" <[EMAIL PROTECTED]> wrote: > > Manually getting rid of those *~'s isn't really an answer, either. I think > a package should have the right to rm -r any directory that's not used by > another package, empty or not.
(The following example from a discussion quite a while ago, and is from memory, so the details (directory names, exact package names, etc.) are probably wrong. Just consider the concepts, please.) What about a database package, such as msql, that creates the actual database/index/whatever files under /var/msql/databases? Should it remove those when purged? The user had no choice about where they are created, and in fact doesn't really know/care about there existence, so long as the appropriate SQL calls work. What about if you're in the middle of changing news servers, and you want to get rid of the old config files. Should the purge blow away the news spool as well? Here's an exact example: The cron package owns /var/spool/cron/crontabs. No other package uses it (that I'm aware of...see point below). I expect that if I rm'd that directory when cron was purged that I would get a few complaints. User crontabs are equivalent to hidden database files: the user has no choice about where they are stored, but they are the user's property, not the package's. How does a package *know*, absolutely, that a given directory is not in use by another package? I agree with your issues about cruft, but it's really difficult to programatically determin the difference between cruft and valuable user data. I would much rather error on the side of caution. Steve
