Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[Stefan Monnier]

> I'm unconvinced. I think a build should be repeatable. Imagine bisecting
> a bug that has come up in an ELPA package when you are not sure whether
> it's the package or Emacs core that has broken things.

That's already a problem with Elisp packages (whether from GNU ELPA or
elsewhere), so the fact that we bundle some of them doesn't make much of
a difference in this respect.

Dependencies between them *should* be limited so that GNU ELPA packages
can be used with various Emacs versions (and vice-versa).

>> I think on Emacs `master` we won't want to use fixed SHAs but will just
>> use whatever's on `master` of elpa.git.  On the release branch, we'll
>> probably want to be more specific, using corresponding branches.
> That might mean multiple branches of master which would produce a very
> cluttered namespace. The problem is that ELPA currently uses a different
> (non git) mechanism to identify the current version of every package; so
> you can't identify this from git metadata (except for SHA!).

I don't know what you mean.  A branch/tag is just a name for an SHA, so
I can't see why a branch/tag wouldn't work where an SHA does.

In terms of namespace, we'd simply use an appropriate naming scheme,
of course.

>>> Finally, neither solve the problem -- if a branch or tag is add
>>> EMACS/elpa/Makefile.in which exists in the ELPA repo, but not in the
>>> clone on the local machine the build will fail.
>>
>> I think the use of branches/tags will make it sufficiently infrequent
>> that it's not a big deal.  Also the build shouldn't completely fail.
>
> Beyond removing the configure option, it will fail at the moment. I
> could do something else beyond that.  But surely, by default, the build
> should fail, if something fails?

I think currently I'd want bundled-GNU-ELPA packages to be treated as
"GNU ELPA packages pre-installed for the user's convenience" rather than
as "core packages that you can later upgrade via GNU ELPA".
So it's OK if they can't build: Emacs should still be perfectly usable
without its bundled-GNU-ELPA packages (which you can later install via
GNU ELPA anyway).

Maybe in the future, we'll want to allow some bundled-GNU-ELPA packages
to be more important (e.g. be *necessary* for example because they're
used by some core Elisp packages), but there's no need to cross that
bridge now.


        Stefan