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