Re: feature/integrated-elpa 4f6df43 15/23: README added

[Eli Zaretskii]

> From: Achim Gratz <address@hidden>
> Date: Tue, 18 Oct 2016 20:48:29 +0200
> 
> Eli Zaretskii writes:
> > That just means installing a new version needs to remove the previous
> > version's files first, that's all.  It has nothing to do with
> > load-path.
> 
> That's simply not an option when a user wants to install an updated ELPA
> package in his home directory while the system administrator keeps the
> Emacs installation as-distributed.  In other words, you'd kill _the_
> feature that package.el was supposed to give mere users and arguably the
> main selling point.

If no better solution comes up, it would mean the user will have to
restart Emacs.  Hardly a catastrophe.

> >> Org-mode v1 comes with org-html. v1 is distributed through ELPA.
> >> Org-mode v2 comes with ox-html. We upgrade v1 to v2, and v1 is removed
> >> from the path. org-html is no longer loadable.
> >
> > org-html doesn't need to be loadable if it doesn't exist in the new
> > version.  Again, nothing to do with load-path.
> 
> But in the situation explained by Phillip it _is_ loadable, even though
> it must not be.  If in fact you have an autoload pointing to a file that
> no longer exists or doesn't contain the autoloaded function anymore,
> then a modification of load-path after that autoload has been generated
> won't help at all.

Restarting Emacs will solve that.

> Well, start with cleaning up load-path and autoloads in a way that any
> built-in package can be cleanly deactivated: after deactivation Emacs
> behaves as if the package wasn't present.
> 
> If you think you don't need this, I have done some experiments to excise
> the remnants of a built-in package from Emacs' data structures
> (autoloads and customization), but there really isn't any supported way
> to do that and I consider the whole thing incredibly brittle since I
> need to manipulate internal data structures to do that.  At the minimum
> you'd need official support for re-defining an autoload so it stops
> pointing at the wrong load-file.

These problems need to be attacked and solved.  But saying that
instead of solving them we should fundamentally change our lisp/ tree
is IMO not the right way.  It's akin to searching the keys where the
streetlight is, not where they were lost.  We need to define the goal,
and then work towards implementing it, not the other way around.