[Fedora-packaging] Emacs add-on packaging and triggers

[Jonathan Underwood]

Hi,

The current (X)Emacs add-on packaging guidelines cover how to package
add-on packages for (x)emacs, such as things like AuCTeX, Muse etc.
These guidelines also cover the situation where a package Foo has a
few Emacs helper files (eg. which add a mode to emacs to be used with
the main package) - presently the guidelines stipulate that the emacs
files are placed in a sub-package, emacs-foo.

For example, the main gnuplot package creates a sub-package called
emacs-gnuplot containing the files to enhance editing of gnuplot input
in Emacs. Other examples include emacs-git, emacs-mercurial etc etc.
It is this sort of situation that this present email is concerned with
i.e. where a package is not principally an add-on for Emacs, but adds
some elisp support files for the program.

When I was drafting the guidelines there was a different practice that
I wasn't aware of at the time whereby the elisp files are packaged
with the *main* package (i.e. not an emacs-foo subpackage) and
triggers are used to create symlinks to these files in the Emacs tree
when/if Emacs is installed. Amongst other things, this negates the
need for the package to have Emacs as a dependency. Examples include
rpmdevtools, maxima and others.

Briefly, this strategy is schematically below for a single file. I'm
not using %_datadir etc macros for clarity:

%install
...
install foo-mode.el %{buildroot}/usr/share/foo/emacs/foo.el

install %{buildroot}/usr/share/emacs/site-lisp{,/site-start.d}
ln -s %{buildroot}/usr/share/foo/emacs/
%{buildroot}/usr/share/emacs/site-lisp/foo
...

%triggerin -- emacs-common
if [ -d /usr/share/emacs/site-lisp ]; then
    rm -rf /usr/share/emacs/site-lisp/foo
    ln -sf /usr/share/foo/emacs /usr/emacs/site-lisp/foo/ ||:
fi

%triggerun -- emacs-common
if [ $2 -eq 0 ]; then
    rm -rf /usr/share/emacs/site-lisp/foo ||:
fi

%files
...
%ghost /usr/share/emacs/site-lisp
....


I've simplified the above for clarity just to convey the essence of
it, and obviously the same strategy applies to xemacs. Also I've
skipped any byte compilation details.

One of the things that should jump out at you is that every package
adopting this strategy will own /usr/share/emacs/site-lisp - a
directory owned by the emacs-common package.

The key question is: do we want to be allowing this strategy verses
the alternative of having a separate emacs-foo subpackage?

On the plus side it allows the user to not have to go hunting to
install an emacs-foo add on package after she's installed foo in order
to get emacs support working. And it manages to do this without the
package foo pulling in Emacs.

On the negative side it uses triggers, and is (in my opinion) more
complex than a separate sub-package. Nicholas Mailhot in a discussion
related to this issue voiced concerns that "triggers are very
difficult to maintain and master long term since it's
code from one package that fires when another package is installed
with not warning, making install logs useless to understand
problems."[1]

I'd like to get opinions on this issue with a view to drafting a
change to the emacs add-on packaging guidelines IF this strategy is
considered acceptable. On the other hand, if this sort of thing isn't
acceptable I'd like to help fixing the packages which do use this
strategy presently. Right now, I personally have mixed feelings about
it, and I would very much welcome other thoughts.

Best wishes,
Jonathan.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00186.html
(and other messages in the thread).