[Top][All Lists]

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

Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

From: Phillip Lord
Subject: Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
Date: Mon, 19 Sep 2016 17:00:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>> The competing proposal is to have a checkout of elpa.git
>>> within/alongside that of emacs.git.
>> The significant disadvantage to this is that if we want a stable release
>> of Emacs, all the ELPA packages in the tar ball now get tied to the
>> emacs release schedule, because all of the files in the checkout of
>> elpa.git will be at the same commit.
> Indeed.  There are factors that can minimize the impact, tho:
> - packages in elpa.git should usually not be "crucial", so it's
>   hopefully acceptable to bundle whichever revision was current at some
>   particular point in time.  Users can easily update them afterwards.
> - we'll definitely want the Emacs release to refer to a particular
>   commit on elpa.git, and it's likely that this commit will be on
>   a branch where we can apply some fixup when needed (hopefully rarely).

I fear that this has to be on a per-package basis though, since the
packages update to new release versions independently of each other. I
guess we can make ELPA generate this data, since something in the build
knows that this has happened.

>> Unless we move all the files in ELPA git to be external branches.
> Of course, that's another option.  We should rework the GNU ELPA
> building scripts to make this scale better, tho (such a rework would be
> beneficial for many other reasons anyway).

Taken to the extreme, we could just go the MELPA route; the ELPA repo
contains recipes, with the packages stored elsewhere (or on an external


reply via email to

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