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

[Eli Zaretskii <eliz@gnu.org>]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Andy Moreton <andrewjmoreton@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 17 Oct 2016 16:09:15 -0700
> 
> PL> I think it's decision time. I am happy to carry on a little further with
> PL> the package.el based approach that I have outlined, fixing the one
> PL> significant issue with it and then I will stop. If you don't want to go
> PL> this way, that's fine.

Sorry, I don't understand the kind of decision that is being
requested.  I understand that one alternative is that you "carry on a
little further" with your approach, although I'm vague about the
details of that, or what is your goal.  But the other alternative is
entirely unclear to me.  What is it?

> At this time, I don't want to go "full package.el".  However, I'd like to
> include it, since it's key to how users interact with ELPA-based packages.

I don't think I understand what does "full package.el" mean.  However,
package.el is already included, it's in lisp/emacs-lisp/.

> I think Eli said it best:
> 
> EZ> We need to adapt package.el to the new needs. It was not written with
> EZ> these goals in mind, so it needs to learn new tricks. Throwing it away is
> EZ> not acceptable, but neither is blindly accepting its current assumptions,
> EZ> which were not designed for the use case we are discussing.
> 
> So let's not move to "directory per package", but let's do support "properly
> upgrading a package that came with the distribution".

That's obviously fine with me ;-)  I just am not sure this is one of
the alternatives that Phillip considers.

Thanks.