[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Tue, 18 Oct 2016 09:09:44 +0300

> From: John Wiegley <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  Andy Moreton <address@hidden>,  
> address@hidden
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]