Manoj Srivastava <[EMAIL PROTECTED]> writes: > Also consider the fact that all maintainers may not have > enough resources to have all possible flavours of Emacsen on their > machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule, > Xemacs-no-mule, ...), and keep track of which versions were elc > compatible anyway.
Read my mind. I actually had this objection in my previous mail, but took it out since it seemed a littly weaker and I wanted to stick with one point at a time. > On the other hand, some packages (Quassia gnus and VM are examples) > that do funny things in the Makefile in order to compile the el > files; it is not just a matter of > # $(EMACS) -batch -f batch-byte-compile *.el Yeah, my idea certainly won't work for every elisp package, but it would hopefully work for some. > Alternately, each maintainer can maintain a package for one > flavour of Emacs ;-(, and have co-maintainers for ther > flavours. I thought of that too, but that's certainly a little ugly. In the end, though, it may be necessary. As mentioned above, some packages may just fit the compile at install mold. > ps. Oh, I, too, thought of making public my private quassia gnus > package, but it is way too volatile, I think, for general > distribution. I'd put it in experimental. > It is not 10M, BTW, just 5675K. I was talking about the case where you had to have all the .elc files for all the byte-incompatible emacsen within one debian package. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
