Re: Adding ELPA to Emacs core

[Phillip Lord]

Achim Gratz <address@hidden> writes:

> Phillip Lord writes:
>> One thing that does worry me is that it means Emacs source as references
>> to ELPA git. If Emacs (or ELPA) ever needs to move VCS, it's going to
>> require some significant hackery.
>
> Well, if you replace those SHA you were previously talking about with
> tags, then the required hackery gets significantly reduced.  And no, I
> don't think that EMACS needs to be able to reference any SHA directly
> since ELPA is well enough under control to be able to place tags where
> you need them, maybe even of the form emacs-x.y.z or similar so it
> becomes clear which of these are in use where.  Naming the tags
> explicitly to indicate Emacs' use of them would certainly help any
> maintainer who would want to backport important patches to a branch that
> older Emacsen can use.


Yeah, I thought about that. But tags are just aliases for SHAs so I am
unconvinced this reduces the hackery that would come if we were to move
VCS. So, for example, we move to nugit (the new VCS I am not working
on). git tags would have to be translated to nugit tags. But, if we
could do this, we could just put git SHAs onto nugit as a nugit tag; or
we could edit Emacs git history so that git SHAs become nugit
identifiers.

Of course, my current solution does allow use of tags instead of SHAs,
since you can use anywhere a SHA is valid in git, you can use a tag. But
I don't share your confidence that tags could be controlled on
ELPA. There are multiple branches, and even on master the "current
version" maps to multiple commits. So, you need "A-emacs-x.y.z" and
"B-emacs.x.y.z" where A and B are package names. Putting this much
semantics in a string goes against my better judgement, I think.

Phil