Re: Taking over production of emacs20 package.
Manoj Srivastava <srivasta@datasync.com> 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 <rlb@cs.utexas.edu>
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: