Re: emacsen: need plan to fix leftover cruft in share/emacs/XX.Y...

[Rob Browning <rlb@cs.utexas.edu>]

Manoj Srivastava <srivasta@debian.org> writes:

>  Well, how do we handle the possibility of having an add-on package
>  that is only good for emacs-20.6, but conflicts with something in
>  emacs 20.7?

Well, it won't be able to exist once you upgrade emacs20 to a 20.7
version anyhow.  We don't allow simultaneous 20.X versions to exist.
In any case you want to allow parallel installs, you have to have a
new flavor: emacs19, emacs20, emacs21, xemacsN, etc.

>  Seems to me the bug here is packages not removing cruft from the
>  site-lisp directories; the solution should be to fix the add-on
>  packages, not to go through contortions and changing our packaging.

Fair enough, but on the other hand, if there is a fairly simple change
we can make that makes it easer to DTRT for the add-on packages (and
I'm not saying I know for sure whether or not this is a simple change
yet), then it might minimize the overall effort...

>  I vote we file important bugs against the packages in question (for
>  violating emacsen policy); and not change policy to accomodate
>  buggy packages. That, apart from being wriong, really sets a bad
>  precedent.

This might work.  I'd be happy to try it if this is the consensus.
It's certainly a more general solution, if workable, which also covers
any other cruft, even cruft outside the one directory I was talking
about.  And as a general principle, I agree that unless it the info
required to do the job's not available, packages should clean up all
their droppings.

>  incidentally, how many packages are guilty of leaving cruft behind,
>  so we have an handle on the size of the problem?

>From looking at /usr/share/emacs/20.{2,3,4,5,6}/ on my system, the
candidates I see are:

  bbdb
  debview
  psgml
  tdtd
  auto-pgp (a top level file, no less - I thought I disallowed that...)
  ilu-elisp
  gnuserv
  mailcrypt
  dpkg-dev
  gri-mode

So, not too bad.  I suppose it could be considered a bug if they don't
clean up all their current stuff on emacsen removal/upgrade, and also
recommended (a bug too?) that they clean up all their older cruft (for
the given emacsen flavor) in their postrm.

i.e. bbdb would need something like

  rm -rf /usr/share/emacs/20.*/bbdb

in its postrm action for the emacs20 flavor.

So I'd be happy with your solution, Manoj.  It's certainly less work
for me.

Opinions?

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930