Re: Taking over production of emacs20 package.
Rob Browning <rlb@cs.utexas.edu> writes:
> OK, I haven't investigated the compilation resource requirements that
> thoroughly [1],
Well, neither have I, so you are excused :-)
> [1] Though is it really that big a deal as long as it gets forked off
> to the background like the TeX or manpage rebuilds?
Imagine the initial dselect session. A zillion packages with elisp
files are being installed simultaneously with one or two emacsen...
> For example, I eventually want to provide a gnus add-on package that
> contains the latest "bleeding-edge" gnus for those interested. It
> really *has* to have all the files byte-compiled. If the files are
> generated at install time, the .deb file (uncompressed) will be about
> 800K. If I include the .elc files pre-generated, the package it'll
> probably be about 10MB. What's worse, people who don't have both
> emacs and xemacs installed will be wasting about 5MB of hard drive
> space for no reason.
You have a good point there (and I would love the bleeding-edge gnus
package :-).
May I suggest a middleway: You write your compilation program as you
intended, but instead of calling the program from the postinst
scripts, it is left in /usr/sbin for the user to run manually. The
postint (and the user manual) could write a warning telling the user
to run the script. This way it only has to run once when multiple
packages are installed. And the system should be functional even if
the .el's are uncompiled. (Maybe the program should also include an
option for cleaning .elc's if an emacsen is uninstalled?)
- Sten Anderson
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: