Re: Installing binaries with package.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

SM> Notice that ELPA packages have always shipped in source form (even the
SM> .el files are byte-compiled on the user's machine).  So it's only
SM> natural to expect dynloaded modules distributed via ELPA to be
SM> distributed in source form and compiled during installation.
> Help me understand.  Say user installs module FOO-1 which binds to
> library BAR-1.  User upgrades BAR-1 to BAR-2 or uninstalls BAR-1.
> What happens?

Good question, but that seems unrelated to the issue of how the user
gets the compiled version of the module.  If she gets it from ELPA
somehow (whether compiled locally or not), then we have this problem
of detecting and reacting to a change in the underlying
OS-provided libraries.

Beside the issue of detecting, the "reacting" part should basically
re-compile the package, and I think package.el should generally move
towards better supporting recompilation of its packages (not just for
dynload modules, but also for Elisp), including keeping several compiled
versions (in case you want to use the same package with different Emacs
versions and we haven't managed to preserve compatibility at the
compiled-package level).

> What happens to users that don't have a compiler?

The way I imagine it working, ELPA packages are basically distributed in
source form, and we'd encourage users to compile them locally.  We could
complement that with a separate repository of precompiled versions of
some combinations of package/OS/architecture.

> Do you think OS distributions will pick up the module distribution
> piece like they did with Python, Perl, etc.?

Not sure what you mean.  Debian does already provide various ELPA
packages, so I guess the answer is yes, but I don't think this will be
of much help to the above problems (it just lets the user choose whether
to install a package via ELP or via dpkg, and only for those packages
which Debian has packaged as a dpkg).  IOW, they do a parallel job,
which doesn't really help us (not to imply that it hurts, tho).


        Stefan