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

Re: Bug#329114: Please don't shadow emacs-snapshot packages

Romain Francoise <rfrancoise@debian.org> wrote:

> Peter Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> > 1- Perhaps if I don't explicitely add
> >    /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it
> >    will get added automatically at the tail end, because it is a
> >    subdirectory of /usr/share/emacs/site-lisp ?
> Nope, it won't be added automatically.

Okay, thanks.
> > 2- Perhaps emacs-snapshot can be modified to have it's generic load-path
> >    all done by the time the /etc/emacs startup files are run.  That
> >    way. add entries at the tail end of the load-path would indeed yield
> >    the expected result.  For everybody.  Not just me.
> Its load-path is already 'all done' by the time the Debian startup
> scripts run, or things would break in horrible ways.
> Your problem is that this code from debian-startup.el (in the
> `debian-run-directories' function) stores the original load-path before
> running the scripts and then explicitly overwrites load-path, adding any
> items added by the Debian startup scripts at the head of the original
> load-path:
> ,----
> | ;; restore the old load-path -- including any new paths added by
> | ;; files loaded in directory traversal.
> | (let ((add-on-package-paths 
> |        (delq nil (mapcar
> |                   (lambda (item)
> |                     (if (not (member item new-path))
> |                         item
> |                       nil))
> |                   load-path))))      
> |   (setq load-path (append add-on-package-paths old-load-path))))))
> `----

Well, I'm sure that was done for a valid reason.  But isn't it horribly
broken?  It means we can't do what's best for the load-path.
> This is why your site-lisp directory added at the end of the load-path
> in emacs-goodies-el's startup script ends up being moved before the
> system load path items after `debian-startup' returns.
> So, we could try to fix emacsen-common by changing this code, or we
> could try my (admittedly cumbersome) symlink solution...

If I have to resort to the symlink solution, everybody who gets this
problem will have to do the same thing.  If emacsen-common gets fixed,
it's fixed for everybody!

How likely it is that we can get emacsen-common fixed?  That package has
seen a single upload since `oldstable' (woody?)

I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the
load-path altogether, except that breaks the ability to jump to the code
when viewing variables and functions via `C-h v' and `C-h f'.  Much
easier and cleaner than maintaining a collection of symlinks...


Reply to: