Rob Browning wrote: > Peter S Galbraith <[EMAIL PROTECTED]> writes: > > > > This is an ugly hack I wouldn't want in my packages. > > > The proper place to remove that cruft is > > > /usr/lib/emacsen-common/packages/remove/<package>. > > > > I agree. That's where it should be. > > I'm still not sure I agree, though I need to think more about the > practical implications of each of the possibilities (handling it in > emacsen-common vs handling it in the add-on packages). > > Handling the cleanup in emacsen-common to me still seems somewhat > wrong. I don't really like the idea of deleting files and directories > there that were created/installed by other packages.
Except that's not really the case, emacsen-common is only running a file _provided_ by those add-on packages for which it is deleting files. So it made no decision on what to delete. The add-on package maintainers did that when they wrote their emacsen-common scripts. > Further, it looks like most packages have been cleaning up correctly, > so it's starting to seem to me like it's excessive to have a global > solution in emacsen-common to fix bugs in a few packages. > > So right now I'm leaning in favor of requiring add-on packages to > clean up their own mess, though I'd be happy to add some > infrastructure to emacsen-common, if needed, to make this easier -- I don't think any is needed if we forget about old cruft and just deal with future cruft. > i.e. does the removal script need to provide the current emacs > major/minor version. I don't think so, but if we need something like > that... No need. e.g. when you remove emacs-20.3 in favour of emacs-20.7, the script /usr/lib/emacsen-common/packages/remove/gri would run and delete /usr/share/emacs20/site-lisp/gri-mode.CompilationLog.gz which is, in fact, a symlink to /usr/share/emacs/20.3/site-lisp/gri-mode.CompilationLog.gz Right? > > Are we content with fixing packages for future cases? > > Or should we attempt to detect cruft left-over from prior buggy > > packages? (I'd vote for future cases only to simplify the code > > we put in). > > If it's not much more hassle, then I think it'd be a lot nicer to > handle all the old mess. If we know what needs doing, and we can do > it easily, why not? Worst case, I suspect it's probably 3-4 extra > lines in a postinst that most of the time will just sit around doing > nothing, and will guarantee that users don't have random junk left > lying around on their machines. Well, the current mechanism can safely deal with future cruft. To deal with old cruft, I'd need to do something in prerm like: rm /usr/share/emacs/*/site-lisp/gri-mode.CompilationLog.gz and this would delete compilation logs of currently still installed emacs flavors. :-( Peter
