Peter Galbraith <[EMAIL PROTECTED]> writes: > Manoj Srivastava <[EMAIL PROTECTED]> wrote: > >> Please join me in a new thread about load path issues in >> Debian's emacsen. > > As I mentionned earlier, I think I have done something sensible with the > emacs-goodies-el source package (binary packages emacs-goodies-el, > debian-el, gnus-bonus-el, devscripts-el, vm-bonus-el, dpkg-dev-el), so > that's a starting point to quickly look at. It doesn't seem to be > responsible for any nasty shadows. > > The source files go in e.g. /usr/share/emacs/site-lisp/emacs-goodies-el/. > This is typical. That directory isn't added to the load-path. That > isn't typical. > > The byte-compiled files go in > e.g. /usr/share/emacs21/site-lisp/emacs-goodies-el/ and that is added to > the load-path. That is typical. > > The source elisp files are symlinked into the byte-compiled directory of > each flavour. That is not typical. > > This has the advantage that source and byte-compiled files are in the > same directory, and I can include in the load-path only files that are > compatible with each flavour. > > I will likely change my other Emacs-related packages to do the same (if > they don't already, I'm not sure). This would include mh-e and gri-el. > That is, unless we come up with something better.
I do this for muse-el, planner-el, and erc as well. Consider the following a request for comments, and not a formal proposal, unless no comments about it are emailed to this list within a week, in which case it becomes a proposal. I propose adding the following paragraph to the end of Section 9 of the debian-emacs-policy document. If an Emacs add-on package compiles its Emacs Lisp sources, its Debian startup script should only add /usr/share/<flavour>/site-lisp/<package-name> (and its subdirectories of compiled code, if applicable) to the load path, rather than /usr/share/<emacs>/site-lisp/<package-name>. If a subdirectory of /usr/share/<emacs>/site-lisp/<package-name> contains uncompiled Emacs Lisp code, it may also be added to the load path. I also propose creating a Section 6.E in the same document with the following content. If an Emacs add-on package compiles any of its Emacs Lisp sources, it should install the compiled bytecode files to /usr/share/<flavour>/site-lisp/<package-name>. It should also create a symlink for each Emacs Lisp source file in /usr/share/<emacs>/site-lisp/<package-name> and store the symlink in /usr/share/<flavour>/site-lisp/<package-name>. If any byte-compiled Emacs Lisp code is stored in a subdirectory, similar treatment should be used. This ensures that Emacs will be able to locate the source code for the add-on package when using M-x find-function and similar functionality. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC |_] | \| |_| Reclaim your digital rights by eliminating DRM. See http://www.defectivebydesign.org/what_is_drm for details.
pgpy2lVf6DKyg.pgp
Description: PGP signature
