[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy additions (was: load-path shadows)

Michael Olson <mwolson@gnu.org> writes:

> 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.

So, what's the next step for getting these propositions acted on?

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.

Attachment: pgpFFcNuNe7o5.pgp
Description: PGP signature

Reply to: