[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> > 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.  :-(


Reply to: