Re: Taking over production of emacs20 package.
>>>>> "MS" == Manoj Srivastava <srivasta@datasync.com> writes:
MS: Hi, Also consider the fact that all maintainers may not have
MS: enough resources to have all possible flavours of Emacsen on
MS: their machines (Xemacs19, Xemacs20, emacs19, emacs20,
MS: emacs20-no-mule, Xemacs-no-mule, ...), and keep track of which
MS: versions were elc compatible anyway.
MS: On the other hand, some packages (Quassia gnus and VM
MS: are examples) that do funny things in the Makefile in order to
MS: compile the el files; it is not just a matter of # $(EMACS)
MS: -batch -f batch-byte-compile *.el
MS: Alternately, each maintainer can maintain a package for
MS: one flavour of Emacs ;-(, and have co-maintainers for ther
MS: flavours. Autocompilation may not be quite as trivial as it may
MS: seem (though by no means impossible).
I agree.
What I would prefer as a user is to have multiple packages:
foo-el.deb
foo-elc-emacs.deb
foo-elc-xemacs.deb
foo-elc-whateveremacs.deb
...
In debian/rules could be checked, which Emacsen are installed and only
appropriate elc packages are created. So different co-maintainers of
the foo with different Emacsen could produce different sets of elc
packages just by building debs from the source package. There are some
problems with maintaining the source package (the primary maintainer
should incorporate changes of other maintainers, for Emacsen he has not
installed), but I can't imagine better solution.
Note that in this case the building of foo is system installation
dependent. However produced deb packages are not system installation
dependent, only the *sets* of builded deb packages are different.
Milan Zamazal
--
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: