Re: emacsen: need plan to fix leftover cruft in share/emacs/XX.Y...
"Davide G. M. Salvetti" <salve@debian.org> writes:
> >>>>> RB == Rob Browning [2001-1-23]
>
> RB> From looking at /usr/share/emacs/20.{2,3,4,5,6}/ on my system, the
> RB> candidates I see are:
>
> RB> mailcrypt
>
> I doubt it, please do file a bug if it does. :-)
$ find /usr/share/emacs/20.* -iname "*mailcrypt*"
/usr/share/emacs/20.3/site-lisp/mailcrypt
/usr/share/emacs/20.7/site-lisp/mailcrypt
/usr/share/emacs/20.7/site-lisp/mailcrypt/mailcrypt.elc
It looks like the 20.3 version may have left the dir lying around.
(20.7's the current version).
> RB> i.e. bbdb would need something like
>
> RB> rm -rf /usr/share/emacs/20.*/bbdb
>
> RB> in its postrm action for the emacs20 flavor.
>
> 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>.
Well, add-on packages that leave files around won't need it. Also,
how would emacsen-common know which old directories to clean up --
i.e. which versions for which flavors? On my system, it's
emacs/20.{2,3,4,5,6}, but it won't be for systems that had/have
emacs19, or xemacs. I suppose I could put special code into emacsen
common that tries to act based on the current versions of all
installed emacsen, but this would make me really nervous. If
anything, It seems like it'd have to be cleanup code in all of the
various emacsen's postinsts, and that seems no less crufty than just
mandating that add-on packages clean up their (possibly old) messes.
Further, I'm just not sure I like the idea of emacsen-common deleting
files "owned" by other packages, even if they're not officially owned
as far as dpkg is concerned.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: