RFC: No longer split out Elisp source into sub-packages
While reviewing the (X)Emacs packaging guidelines today when drafting
the (x)emacs-filesystem changes (see other thread) it occurred to me
that we could simplify matters a lot by no longer insisting that the
Elisp source files be shipped in a separate sub-package to the
compiled Elisp. The original rationale was to follow the precedent set
by the main (X)Emacs packages where the sub-packaging of the Elisp
source files was done to save disk space. Nowadays that's much less of
a concern IMO.
Furthermore, having the Elisp source installed is helpful when an
error occurs in the compiled elisp invoking the elisp debugger - the
debugger can find the relevant symbols in the source Elisp if it is
available. In this sense, they are somewhat like the python .py
sources that we ship together with the byte compiled .pyc.
So, I am thinking of proposing that we:
1) Package the elisp source together with the compiled elisp in both
Emacs and XEmacs packages
2) Package compiled and source elisp files together in add-on packages.
This would simplify packaging add-ons, and reduce the number of
sub-packages in the repos (often the elisp source file packages
contain only 1 or two files), reducing the amount of yum metadata etc.
Also, note that the elisp source files can be gzipped and still be
read by (X)Emacs, reducing the disk space required.
Thoughts? If this is seen as a welcome change I'll draft up a guideline change.
Please note that this is entirely orthogonal to the guideline change
related to (x)emacs-filesystem usage that I have already put a ticket
into FPC for.
packaging mailing list