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

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

[ Please remove the Cc to debian-devel in replies.  I just wanted to
  make sure everyone on debian-devel at least saw that this was about
  to be discussed, but let's carry on the rest of the conversation on
  debian-emacsen.  Please do maintain the cc to the bug tracker.
  Thanks ]

I'm going to use bbdb as my whipping boy here, but I'm not implying
any bugs there, it's just a convenient example.

For some of the context, see 

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61167&repeatmerged=yes

The basic problem is that when you upgrade an emacsen (maybe only FSF
emacsen) from one minor version to the next, say from 20.6 to 20.7,
there is cruft left around in the version specific share directories,
in thise example, /usr/share/emacs/20.6.  I believe much, if not all,
of this cruft is due to add-on pacakges, like bbdb, etc. not properly
cleaning up their mess.

One proposed solution was for emacs20, when 20.7 is released, for
example, in its postrm, to just rm -rf /usr/share/emacs/20.6.
However, this doesn't seem like a viable solution; it could mean
removing files that the add on package will (may) expect to be there
when it's removal scripts run.  i.e. this solution would effectively
be doing an rm -rf /usr/share/emacs/20.6/bbdb while bbdb is still
installed.  Responsibility/ownership of that dir, IMO, should be
bbdb's perrogative.

Another solution might be to just require that all the add-on packages
always clean up their mess, and file bugs when they don't.  This might
work, but it's also a bit tricky because it may be hard to make sure
the packages know if/when they're experiencing a minor version
upgrade.  Making them track of that seems like an added pain that we
should avoid if we can.

One of the best solutions I've heard so far, dres and debated the
other night, and that's what I wanted some feedback on.  The idea
would be to just make it so that /usr/share/emacs20/site-lisp is no
longer a symlink to /usr/share/emacs/20.7/site-lisp (to use emacs 20.7
as an example -- same would apply for other emacsen, though), it's a
real directory, and add-on packages would be required to use that dir.
This would eliminate the current cruft problem, but raises a couple of
questions I don't know the answer to ATM:

  (1) In this situation, should /usr/share/emacs/<version>/site-lisp
      be a symlink back to /usr/share/emacs/<flavor>/site-lisp i.e.:
      /usr/share/emacs/20.7/site-lisp -> /usr/share/emacs20/site-lisp?

  (2) Will this cause nasty problems during the package upgrade
      process between two minor versions, i.e. 20.6 -> 20.7,
      including, but not limited to problems caused if/when backwards
      .elc file compatibility is broken?

I think it's at least possible that this would work right as long as
emacsen-common is *really* careful to call the add-on package removal
scripts when the old (20.6) package is being removed, and the add-on
packages are *really* careful to clean up anything that could cause
the new version (20.7) to retch.

Does this sound feasible?  If so, I think it's a lot better than what
we've got now, and better reflects the parameters of the debian
emacsen situation (i.e. it's OK to use share/emacs20/site-lisp and
just not have independent share/emacs20/20.{6,7}/site-lisp directories
because debian doesn't let you have two emacs20 packages installed
simultaneously anyhow).

If everyone thinks this is a suitable solution, I'll rev
debian-emacs-policy, and update emacs20.  I'd like to do this soon,
though so I can clear up the RC bug for emacs20.

Thanks

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