Re: debian-emacs-policy

[Rob Browning <rlb@cs.utexas.edu>]

Package: emacsen-common
Version: 1.3-1
Severity: important

The bug is explained below...

Fumitoshi UKAI <ukai@debian.or.jp> writes:

> > Consider, for example, a package that has all its files in
> > /usr/share/<emacs>/site-lisp/<package-name>/lisp.  Why should
> > /usr/share/<emacs>/site-lisp/<package-name>/ be in the load path?
> 
> Why don't decide which to be used for debian elisp add-on?

This is imposing more structure on the add-on package maintainers than
I want to.  Consider a case where the upstream package has the lisp
files across several subdirectories like this:

  /usr/share/<emacs>/site-lisp/<package-name>/main
  /usr/share/<emacs>/site-lisp/<package-name>/support
  /usr/share/<emacs>/site-lisp/<package-name>/utils
  /usr/share/<emacs>/site-lisp/<package-name>/print
  
or whatever.  I don't want the maintainer to have to move everything
just to comply with unnecessary policy.

> Which elisp file should we set load-path for elisp-package?
> 
> /etc/<emacs>/site-start.d/NN<package>.el{,c} would not work
> because debian-run-directories reset load-path after load it.

Ahh.  Now that is a *great* question.  If I'm not overlooking
something because I'm tired, you've just found a *huge* bug in
emacsen-common.  How are other packages getting around this?  I'll
check it out and fix it posthaste.  Notice that this email is also a
bugreport :>

I'll recode it to do the right thing by looking at a "diff" of the
before and after load-paths.

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org