[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: Fri, 30 Sep 2016 14:06:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Cc: address@hidden,  address@hidden
>> Date: Fri, 30 Sep 2016 11:43:10 +0100
>> > EZ> We should at least try, IMO, and not dismiss that possibility before we
>> > EZ> really see the difficulties and can assess them.
>> >
>> > I agree with Eli here. The more "natural" we can make the ELPA integration,
>> > the better I think it will be, since it will allow the flexibility for 
>> > either
>> > approach, depending on what is best.
> My suggestion is none of the above.  We should instead try to arrange
> things so that when a Emacs is built from the repository, the build
> process updates any packages from ELPA that need to be updated, as
> part of the build.  And when an Emacs release tarball is tarred, each
> package has its files put/updated in the corresponding directory under
> lisp/.  If we succeed doing this, there will be no difference between
> packages in the Emacs repository and in ELPA, as far as building and
> releasing Emacs is concerned.
> Can we try doing that?

We could do, but then it means that packages will use two different file
organisations; one for when they are in package.el format, and one where
they are not. Aside from being more work for the build, I think this
will be fragile. Just as a simple example consider this file layout:



where does simple-test.el go?

Emacs currrently has two systems for building packages -- one in core,
one in package.el format. Adding support package.el format in core means
that package developers only have to support one of these.


reply via email to

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