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. 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.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... > 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. -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
