[ 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 <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
