Re: proposal to (maybe) use "elpa-" package prefix for emacs lisp packages
David Bremner <bremner@debian.org> writes:
> There are two related issues: supporting multiple incompatible
> co-installed versions of (x)emacs, and dealing with upgrades. I think the
> former is the main hurdle: new versions of GNU emacs are _supposed_ to
> run old versions (the other direction definitely doesn't hold:
> e.g. emacs24 compiled byte code won't run on emacs23).
It's also (currently) "emacs24 vs emacs24-nox", etc., since I don't know
for certain that Emacs can't produce byte code that differs in ways that
matter when compiled with the various options. But if it can't, that
would definitely be a simplifying assumption.
There may also have been issues with macros, which if I recall
correctly, is one of the reasons we currently rebuild everything at
install/upgrade. It's definitely why we started always rebuilding all
of the emacsXY byte-code at package build time (i.e. not using the
upstream elcs. Of course now that I build directly from git, there
aren't any upstream elcs to throw away).
And with respect to triggers, I've investigated that a couple of times
now at some length, and the current emacsen-common arrangement was the
best I could do. Triggers had limitations (which I can't currently
remember) that wouldn't allow us to handle all the relevant corner
cases, given inter-package dependencies, and parallel installs/removals.
That said, we probably could build all the relevant byte code at package
build time (each add-on would have to have a build-dep on all of the
relevant emacs* flavors). In the past, I believe that was considered
too much archive bloat.
Hope this helps.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: