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

[Phillip Lord]

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
branch).

Phil