Rob Browning <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
