David Bremner <brem...@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 -- To UNSUBSCRIBE, email to debian-emacsen-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uajbo0c....@trouble.defaultvalue.org
