On Mon, Jul 13, 2015 at 08:07:04PM +0200, David Bremner wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > Great to eliminate another class of maintainer scripts in favor of > > something declarative. Does this require triggers, or no action at all > > at installation time? > > for the current source-only-version, no action at install time, and no > startup files installed in /etc/
Awesome. > > > > Could this system support byte-compilation in the future? > > > If nothing else, it could use the existing emacsen-common setup with a > bit more effort (elpa packages need to know the actual emacs upstream > version e.g. 24.5, not not just the "flavour" emacs24). Why? Do elpa packages break with each new minor release of Emacs? > > For that matter, is there any fundamental reason that byte-compilation > > couldn't occur at package build time on the buildds, rather than at > > installation time? > > 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). That doesn't seem too hard to solve. There aren't that many interesting versions of emacs around simultaneously, and they don't change very often. Elisp packages could just depend on a package that builds all the necessary bytecode automatically; that same package would provide the necessary substitution variable for a versioned dependency. Then, when the set of emacs packages changes (either by packaging a new one or dropping an old one), that helper package would change, and any packages depending on it would just need a rebuild triggered. If there's a concern about bytecode size, the bytecode files could be shipped in a separate package. The only cases that wouldn't work automatically would be the same ones that need work today: something that works with emacsN but fails with emacsN+1 because it needs source-level changes. The major advantage would be reducing install time, especially on slower systems. - Josh Triplett -- 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/20150713192805.GA14627@jtriplet-mobl1
