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 <email@example.com> PGP=E80E0D04F521A094 532B97F5D64E3930