Your message dated Sat, 19 Jan 2013 10:25:59 -0600 with message-id <[email protected]> and subject line Re: Bug#454778: Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories has caused the Debian Bug report #676424, regarding emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 676424: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676424 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: emacsen-common Version: 2.0.3 Severity: serious Hi, the line (setq load-path (append add-on-package-paths old-load-path)))))) in debian-run-directories in debian-startup.el puts directories which packages have been added to load-path with debian-pkg-add-load-path-item at the head of load-path, _before_ the "/usr/local" entries in load-path. This makes the requirement in the Debian Emacs policy 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. an absurdity. Even worse, packages that work fine may break when they switch to use debian-pkg-add-load-path-item, because the order in the load-path is wrong. For an example, consider coq and proofgeneral and assume both packages solely use debian-pkg-add-load-path-item (which is not the case right now). coq installs 50coq.el, which adds /usr/share/emacs23/site-lisp/coq to load-path. The reorder bug in debian-startup actually causes a (non-fatal) problem during proofgeneral installation, which I am not going to explain here. When proofgeneral is installed it installs 50proofgeneral.el, which adds site-lisp/proofgeneral/{generic,lib} to load-path. When you now start emacs you see all these directories at the head of load-path, before /usr/local items. When you now open a coq file, say x.v, Proof General loads its Coq incarnation and adds site-lisp/proofgeneral/coq to load-path. This will now be added after /usr/local items and appear far after site-lisp/coq. "(require 'coq)" therefore loads site-lisp/coq/coq.el instead of site-lisp/proofgeneral/coq/coq.el and Proof General is completely broken. (Yes, Coq and Proof General should not use the same Emacs feature name for different packages. I am trying to solve this upstream, see http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2012/000241.html) Kevin, you filed quite a lot reports about debian-pkg-add-load-path-item. Would you add a note to all of them, telling the maintainers that their package may break when they switch to debian-pkg-add-load-path-item? It took me several hours to track down this issue, maybe you can one of them save the hassle. Bye, Hendrik Tews -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information
--- End Message ---
--- Begin Message ---Rob Browning <[email protected]> writes: > Kevin Ryde <[email protected]> writes: > >> Hmm. I suppose if an add-on is removed by a flavour upgrade and that >> remove fails for some reason then bits are left behind in what's now an >> old directory. > > I think there were probably all kinds of reasons -- but I'm fairly > certain that we did end up with a lot of dangling X.Y directories before > that change. > >> Are the X.Y bits all unused by debian add-ons now? Or at least are >> supposed to be unused. If so then I suppose it wouldn't matter what the >> X.Y/site-lisp is or is not! :-) -- if that made an empty directory there >> tempting. > > I think it's possible that Emacs may have some "normal" behaviors that > cause it to select the X.Y directory for some things -- but regardless, > having the symlink means that we don't have to care about what current > or future Emacs versions (or packages) do on that front. So with the recent 2.0.5 upload, I believe the original problem may have been fixed (/usr/local/ position in load-path). Accordingly, I think I'll close this bug. If people would still like to pursue the symlink issue, please feel free to clone this bug (retitle, and change the severity), or start a discussion on debian-emacsen. Thanks for all the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--- End Message ---
