Bug#1678: w3-el: no install-info; elisp files; mailcrypt
CD Rasmussen writes: Costa Elisp folk don't tend to separate the source from the executable the Costa way people do with C programs. I'm sorry to hear this was done with Costa VM. 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. 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 mail/itimer only .elc files mail/vm only .elc files tex/auctex mostly .elc plus three .el files, whereas net/w3 el and elc files -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Bug#1678: w3-el: no install-info; elisp files; mailcrypt
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/emacsonly .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
Bug#1678: w3-el: no install-info; elisp files; mailcrypt
Dirk, thanks for including your explanation of the current packaging of elisp files. While it clarified the current condition it also helped me to pinpoint my issue with the treatment of elisp sources. I'm not having a fit over this. If debian distributions are to go against the convention of keeping elisp files as a primary distribution form for the sake of disk space, I can accept that. If we are doing to follow the convention of a different language, I find it unreasonable. If for what ever reason we do separate the elisp source files, I would like to see it stated as a convention to be followed by all elisp related packages and I would want to ensure that when sources are installed that they fall into the same directory as the compiled files. I think the example set by the emacs and emacs-el packages is the correct model to follow. Costa
