Doug Torrance <douglas.a.torra...@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.