Package: dh-make
Version: 0.60
Severity: normal
Tags: patch

The emacsen-startup.ex template in dh_make generates packages which
violate the Debian emacs policy in two respects:

1. They rely on the variable "flavor" being bound to the current emacs
   flavor, but the policy doesn't guarantee this anywhere (it doesn't
   even mention a variable called "flavor").

2. They modify the variable "load-path" directly, which the policy
   prohibits.

These problems are described in (much) more detail below. The attached patch
fixes both these issues.

re 1:

The policy only mentions the variable "debian-emacs-flavor":

  Each emacs binary must set the variable debian-emacs-flavor to be
  the same as the name of the debian-package.

(<http://www.debian.org/doc/packaging-manuals/debian-emacs-policy>
section 2)

Thus the packages which dh_make generates should refer to
debian-emacs-flavor instead of flavor.

It's not immediately clear why the current use of "flavor" instead of
"debian-emacs-flavor" in emacsen-startup.ex even works; AFAICT it's
because the startup files are loaded by the function
"debian-run-directories" in debian-startup.el, which is called by the
function "debian-startup" (also in debian-startup.el), which is passed
the intended value of "debian-emacs-flavor" as an argument.
"debian-startup" is defined

  (defun debian-startup (flavor) [...])

Thus "flavor" is bound to the current emacs flavor within the body of
the debian-startup function, and because emacs lisp is dynamically
scoped, all the functions invoked in the body of debian-startup
inherit that binding. But relying on this behavior is a very bad idea:
If the flavor argument to debian-startup is renamed, all the packages
relying on this undocumented behavior will break. (They would also
break if debian-startup.el were to start using lexical scoping, which
will be available as an option in the next version of emacs.)

re 2:

Debian emacs policy says:

  Emacs add-on packages may not modify load-path directly. They must
  use (debian-pkg-add-load-path-item <path>). This function will make
  sure that their additions end up in the right place -- before the
  emacs system directories, but after the /usr/local/ directories.
  Also, add-on packages will need to either check (fboundp
  'debian-pkg-add-load-path-item) before calling this function, or add
  a dependency on emacsen-common (>= 1.4.14).

(<http://www.debian.org/doc/packaging-manuals/debian-emacs-policy>
section 9)

However, the emacsen-startup.ex template *does* modify the load-path
directly; it should use debian-pkg-add-load-path-item instead.
--- a/lib/debian/emacsen-startup.ex
+++ b/lib/debian/emacsen-startup.ex
@@ -13,12 +13,14 @@
 ;; installed in a subdirectory of the respective site-lisp directory.
 ;; We have to add this to the load-path:
 (let ((package-dir (concat "/usr/share/"
-                           (symbol-name flavor)
+                           (symbol-name debian-emacs-flavor)
                            "/site-lisp/#PACKAGE#")))
 ;; If package-dir does not exist, the #PACKAGE# package must have
 ;; removed but not purged, and we should skip the setup.
   (when (file-directory-p package-dir)
-    (setq load-path (cons package-dir load-path))
+    (if (fboundp 'debian-pkg-add-load-path-item)
+        (debian-pkg-add-load-path-item package-dir)
+      (setq load-path (cons package-dir load-path)))
     (autoload '#PACKAGE#-mode "#PACKAGE#-mode"
       "Major mode for editing #PACKAGE# files." t)
     (add-to-list 'auto-mode-alist '("\\.#PACKAGE#$" . #PACKAGE#-mode))))

Reply via email to