Dirk Eddelbuettel:
I don't want to take them away from anyone, not even from Emacs
specialists. I simply want to have the option of installing them
or not.
Well, you could delete them.
$ (cd /usr/lib/emacs/site-lisp/w3; for x in *.elc; do rm `basename $x c`; done)
If I want to read or modify them, I can always grab the source
package --- as with any C code. But .el is source code, and we
usually hide that from users that want to run binaries from in a
.deb package. All I propose is to do the same with elisp code. And
that idea seems well represented among debian packages. Here's a
quick poll that shows that vm, the example I cited, is not
atypical:
editors/emacs only .elc files
Not precisely -- these are available as a separate package.
mail/itimer only .elc files
mail/vm only .elc files
tex/auctex mostly .elc plus three .el
files,
In my opinion, this is a bug. The .el files should be available in
package form. They are, after all, executable code. [Which is why
I'm still not sure I should compress them for w3 -- once compressed
they're no longer executable code.]
whereas
net/w3 el and elc files
I suppose I could release a w3-elc which has only the .elc files.
Alternatively, I could make it an install-time configuration option to
run that line of code that deletes the .el files for which
corresponding .elc files exist... Actually, I kind of like this idea
-- I could also support compression for those people who want them
handy but need to save space.
I suspect this will become a much bigger issue once we start having
alternative implementations of emacs available. At that point I
suspect I'll have to include something like w3's makefile as well
[because of byte-code incompatabilities].
--
Raul
