Re: proposal to (maybe) use "elpa-" package prefix for emacs lisp packages
On Mon, Jul 13, 2015 at 08:07:04PM +0200, David Bremner wrote:
> Josh Triplett <josh@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
Reply to: