Re: emacsen: need plan to fix leftover cruft in share/emacs/XX.Y...
Rob Browning wrote:
> Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> 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
Reply to: