Doug Torrance <douglas.a.torrance@gmail.com> writes:
Thanks for the note! I considered using dh_elpa when I decided to split
off the Emacs files into their own binary package. But dh_install
already installs them to the correct place, and there are not any test
suites to run. Is there another reason to use dh_elpa that I'm missing?
Pros
----
1) It means that your package will comply with
https://www.debian.org/doc/packaging-manuals/debian-emacs-policy
without any extra effort on your part.
2) the emacs lisp files with be byte-compiled
3) It uses the the standard (package-initialize) mechanism to set up
packages.
Cons:
----
1) It requires some package.el compatible metadata, but it sounds from
below like this should be there anyway.
2) Any debian-specific customization needs to be done via autoloads.
I don't remember if you are doing any of that.
Also, the files aren't in ELPA and upstream at this point is just
targetting MELPA [1], so is the elpa- namespace appropriate?
It's fine. Most the elpa-* packages in debian are not in ELPA. It is
possible to use other names with dh_elpa, but it is less testedm
I also considered using macaulay2-el, but I stuck with macaulay2-emacs
since it mostly matches upstream's name (M2-emacs) and matches with
some similar math-related emacs packages already in Debian
(maxima-emacs and singular-ui-emacs). I'm definitely open to changing
it, though!
My suggestion would also apply to those packages. At least
singular-ui-emacs does not seem to comply with Debian Emacs Policy.