The following list contains the key points of the guidelines. More detail on each of these may be found in the subsequent sections.

\1. Where an add-on package foo is for both GNU Emacs and XEmacs, the main package should be called emacs-common-foo. This main package should contain files common to both GNU Emacs and XEmacs such as documentation etc. Files specific to each of GNU Emacs and XEmacs should be placed in sub-packages as detailed in points 4 and 5 below.

\2. Where a package is specific only to one flavour of (X)Emacs, the main package should be called emacs-foo or xemacs-foo. In both cases, elisp source should be packaged in separate sub-packages as detailed below.

\3. Where a package which is not primarily an (X)Emacs add-on package but contains auxillary (X)Emacs components, these should be placed in sub-packages following the guidelines below.

\4. Files specific to GNU Emacs should be placed in two sub-packages:

\5. Files specific to XEmacs should be placed in two sub-packages:

\6. File locations for GNU Emacs add-on packages:

\7. Files locations for XEmacs add-on packages:

\8. emacs-foo-el must have Requires: emacs-foo = %{version}-%{release}.

\9. xemacs-foo-el must have Requires: xemacs-foo = %{version}-%{release}.

\10. Where it is relevant, emacs-foo and xemacs-foo must have Requires: emacs-common-foo = %{version}-%{release}.

\11. emacs-foo must have Requires: emacs(bin) >= X, where X is the version of GNU Emacs used to build the package.

\12. xemacs-foo must have Requires: xemacs(bin) >= Y, where Y is the version of GNU Emacs used to build the package.

\13. If an add-on package requires only byte compilation of elisp then BuildArch: noarch should be used.

The existence of the GNU Emacs and XEmacs variants makes packaging Emacs add-on packaging slightly complex. GNU Emacs and XEmacs have different philosophies regarding add-on packages.

XEmacs has its own packaging system and maintains and distributes its own library of third party add-on modules. These are distributed in Fedora in the xemacs-packages-base and xemacs-packages-extra packages. GNU Emacs doesn’t have any equivalent system, and third party add-ons are left for the user or distribution to install.

The packaging naming guidelines state that:

Packages of emacs add-on components (code that adds additional functionality to emacs compatible editors) have their own naming scheme. It is often the case that a component will add functionality to several different compatible editors, such as GNU Emacs and XEmacs (and possibly development versions of these editors). The package name should take into account the upstream name of the emacs component.

Where a component adds functionality to more than one emacs compatible editor, the package name should be of the form emacs-common-$NAME. In this case, the main package should contain only files common to all emacs compatible editors, and the code specific to each should be placed in a subpackage reflecting the specific editor $EDITOR-$NAME eg. xemacs-$NAME, emacs-$NAME (the latter being the package specific to GNU Emacs). An example of this scheme can be found in the package emacs-common-muse.

Where a component is designed to add functionality to only a single emacs compatible editor, the main package name should reflect this by being called $EDITOR-$NAME. An example of this situation can be found in the package emacs-auctex, which is built only for GNU Emacs.

Wherever possible, we encourage making an add-on package available for both GNU Emacs and XEmacs. One common case where that is not desireable is when an add-on package is already available for XEmacs in either xemacs-packages-base or xemacs-packages-extra. For example VM (a mail reader for Emacs) is provided for XEmacs in the xemacs-packages-extra package, but is not included in the emacs or emacs-common packages. Therefore it is sensible to create a package called emacs-vm which is the VM package for GNU Emacs only. Another such example is AUCTeX.

Typically, an Emacs add-on package will be compiled from source elisp files. The resulting compiled elisp files will then be included in the relevant emacs-foo and xemacs-foo packages. However, these packages SHOULD NOT contain uncompiled elisp source files which are not required for the program to run. Rather, following the precedent set by GNU Emacs packaging, the elisp source files should be placed in their own sub-packages, named emacs-foo-el and xemacs-foo-el.

The (x)emacs-foo-el packages are similar in many ways to the -devel subpackages for system libraries. It is often the case that byte compiling the elisp source for one add-on will require the presence of the elisp source for another add-on package at build time for example.

You should set BuildArch: noarch for add-on packages which only compile elisp files during building.

If the package building process also compiles programs in other languages, you may need to not set BuildArch.

Add-on packages should have appropriate Requires entries for the flavour of (X)Emacs they are targeted at. Both GNU Emacs and XEmacs are available in two different packages - some details of these packages follow. 1. GNU Emacs is packaged as two variants. The emacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The emacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note:

\2. XEmacs is packaged as two variants. The xemacs package is built with Xorg support to allow the user to run Emacs in a windowed environment. The xemacs-nox package is built without Xorg support and hence allows Emacs to be run only in a console. Note:

Assuming your add-on package will work in both a windowed and a console (X)Emacs session, it is wrong to have Requires: emacs or Requires: xemacs as that would pull in a dependency on Xorg even if the console variants of (X)Emacs was installed. Rather you should use Requires: xemacs(bin) for XEmacs add-on packages, and Requires: emacs(bin) for GNU Emacs add-on packages.

If the package ONLY works with Xorg support built into (X)Emacs, then the packages should have Requires: emacs or Requires: xemacs. This is very uncommon.

It is often the case that a software package, while not being primarily an Emacs add-on package, will contain components for (X)Emacs. For example, the Gnuplot program contains some elisp files for editing Gnuplot input files in GNU Emacs and running Gnuplot from GNU Emacs.

In other words, if a package foo contains components for (X)Emacs, the subpackages containing the files to run the (X)Emmacs components should be called emacs-foo and emacs-foo-el, which own the directories /usr/share/emacs/site-lisp/foo and /usr/share/xemacs/site-packages/lisp/foo respectively. Elisp source files not needed for running the add-ons should be packaged in separate sub-packages emacs-foo-el and xemacs-foo-el, which should Require emacs-foo and xemacs-foo respectively.

This spec-file template for the add-on package "foo" creates 5 packages:

\1. emacs-common-foo is the main package. This should contain files which are common to both the emacs-foo and xemacs-foo subpackages below. Examples of what this file would contain are the package documentation, the COPYING file, the CHANGELOG file etc.

\2. emacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-lisp/foo.

\3. emacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package emacs-foo. This sub-package Requires: emacs-foo, as the directory in which the elisp source files are installed to is owned by emacs-foo.

\4. xemacs-foo. This sub-package Requires emacs-common-foo and contains the files needed to run foo with Emacs only. This package owns the director /usr/share/emacs/site-packages/lisp/foo.

\5. xemacs-foo-el. This sub-package contains the elisp source files corresponding to the compiled elisp files in package xemacs-foo. This sub-package Requires: xemacs-foo, as the directory in which the elisp source files are installed to is owned by xemacs-foo.

For the Requires mentioned in 1-5 above, the exact %{version}-%{release} should be matched.

For convenience, there are two macros at the top of the file which you should customise to your package. You do not have to use the macros placed at the top of the file, but they help readability and make writing a spec file for a new package much quicker.

This is a template for a package for GNU Emacs only. The main package is called emacs-foo and contains all files needed to run package foo with GNU Emacs. There is a subpackage called emacs-foo-el which installs the elisp source files. emacs-foo owns the directory into which it is installed (/usr/share/emacs/site-lisp/foo), and so emacs-foo-el Requires emacs-foo with the matching version and release tag.