[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...

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.

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

> 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 <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Reply to: