[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: