On 27/05/07, Ville Skyttä <ville.skytta(a)iki.fi> wrote:
Regarding the current Emacsen add-on draft,
* Added some more info about requiring a version of (X)Emacs newer than or
equal to the one used to compile the *.elcs, and how to find that version out
dynamically during package build.
Thanks very much, Ville.
* I'd like to see something mentioned about packaging *.el
aren't full blown packages of their own, see for example rpmdevtools.
Yes, actually Tom Tromey had also mentioned this to me privately, and
you're both right - we do need to mention this. There are actually a
lot of cases where a piece of software has a mode for eg. editing
input files for that software.
Another example that springs to mind is gnuplot, which has a
subpackage called gnuplot-emacs which installs
for GNU Emacs in /usr/share/emacs/site-lisp.
There are a couple of things with this which I suppose are
inconsistent with the guidelines for full blown emacs add-on packages:
1) The source .el files aren't in a separate sub-package called gnuplot-emacs-el
2) The files aren't installed in their own sub-directory
3) The info-look.20.[2,3].el files aren't byte compiled (there may be
good reasons for this.
Similarly on my system currently I see the same issues for:
1) rpmdevtools (rpm-spec-mode.el[c],
2) desktop-file-utils (desktop-entry-mode.el[c])
3) libidn (idna.el and no idna.elc)
4) emacs-common (has extra files like php-mode.el, po-mode.el,
python-mode.el, ssl.el not in emacs-common-el and also not in their
I would propose guidelines such as these:
1) Packages which include add on modes for (X)Emacs should package the
byte compiled lisp files for these modes in a sub-package named
foo-emacs and/or foo-xemacs.
2) Packages which include add on modes for (X)Emacs should package the
source elisp files in separate subpackges called foo-emacs-el and
3) Elisp add on subpackages should install their files in an
appropriately named subdirectory of /usr/share/emacs/site-lisp and
/usr/share/xemacs/site-packages/lisp. These directories should be
owned by the foo-emacs and foo-xemacs packages respectively.
4) foo-emacs-el should have Requires: foo-emacs and foo-xemacs-el
should have Requires: foo-xemacs.
These seem logically consistent with the guidelines formain (X)Emacs
add-on packages, but don't fit with current packaging of some
packages. The current situation is rather inconsistent.
I agree with Ville, I think it's important that the draft include
something on this matter.