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

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> Date: Wed, 19 Oct 2016 17:12:30 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > If the old file org-html.el exists in directory DIR1, and the new file
> > ox-html.el that defines the same features lives in directory DIR2,
> > then having DIR2 in load-path ahead of DIR1 will always find
> > ox-html.el before it finds org-html.el.  If the autoloads for symbols
> > previously defined in org-html.el now point to ox-html.el, referencing
> > such a symbol will load ox-html.el because the regenerated autoloads
> > say so.  Right?
> 
> If everybody does the right thing. If not everybody does the right
> thing, the old version gets loaded. Happened to me, it's hard to debug
> and hard to work out what is going wrong.

OK, so we agree that if everybody does the right thing, this will
work.  That's all we need at this point, because we certainly don't
need to cater to packages which do the wrong thing: such packages will
be fixed in no time, because they are bundled and are part of any
Emacs installation.

> >> And, anyway, it's not possible to regenerate autoloads in core
> >> emacs.
> >
> > Why not?  We do that all the time, each time we rebuild Emacs.
> 
> Developers do this all the time, users do not.
> 
> We could remove, of course, put autoloads in user space under the
> control of the user. This is what package.el does.

Exactly.  So we should use what package.el does, only extend it so it
does that correctly for files under lisp/ that come from ELPA.

> >> > If load-path is rearranged when a newer version of Org is installed,
> >> > and org-loaddefs are regenerated, then, after a restart, any 'load'
> >> > and 'require' will find the new files first, and the old ones will be
> >> > effectively invisible to Emacs.  Right?
> >> 
> >> No. They are still there, and are still visible, as long as they are in
> >> the load path.
> >
> > Why do we care that the files are there if no one and nothing is
> > loading them?
> 
> They are loadable.

They are, but if no one is loading them, they don't matter.

> Seriously, honestly, definately, I will stop defending my proposal now,
> because the discussion is not advancing at all.

I hope we've reached the agreement that the lisp/ tree as it is can
continue be used when some packages in it come from ELPA.

Thanks.