Re: Elpa packages and macro dependencies.

[Phillip Lord]

Achim Gratz <address@hidden> writes:
> Again, this in particular is only really a problem for built-in packages
> since there's no way to make Emacs completely forget about the built-in
> package when you happen to install a newer version of it via ELPA later
> on.  When an autoloaded function is moved into a different file in the
> new version, the new autoload definition is ignored (because there
> already is one) and if you try to invoke the function the wrong file
> gets loaded so it doesn't work (the original autoload definition is
> always read during Emacs' startup).  It's admittedly a rare occurence,
> but if you split a single-file package into multiple files or if you
> were to do some refactoring (like the Org 7.x->8.x transistion) it can
> bite you.


I've been bitten by this one.

Would it not be possible to have package.el check when it installs
packages from ~/.emacs.d if that package is also in Emacs core and then
remove the relevant paths from load-path.

So if I have in my .emacs

(require 'org)
(require 'org-latex) 

would work iff org is only in core. But would crash with "cannot open
load file" if org is loaded from ELPA. If it doesn't crash in my .emacs
I am going to get strange errors later anyway, from loading two versions
of org.

All of this could be calculated when a new package is installed, it
seems to me.

Phil