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...
Peter
Reply to: