emacs-devel
[Top][All Lists]
Advanced

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

Re: Adding packages to ELPA


From: Stephen Leake
Subject: Re: Adding packages to ELPA
Date: Sun, 21 Sep 2014 10:05:48 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> Date: Sat, 20 Sep 2014 11:09:15 -0500
>> 
>> > No, I mean that a package that is part of Emacs can be used to create
>> > a separate tarball disregarding the rest of Emacs.  After all, once
>> > you checkout the repo, they are just file in a certain directory.
>> 
>> How would the typical Emacs/ELPA user use that "separate tarball"?
>> 
>> Currently, to release a new version of Ada mode, I just update the elpa
>> repository, incrementing the version in ada-mode.el header.
>> 
>> Then users will see the new version when they next do 'list-packages',
>> and can install from there.
>> 
>> What would that process look like if I followed your approach?
>
> The same.  If you are saying that list-packages currently doesn't
> support the Emacs repo, we should modify it so it does.  It's just
> another repo, after all, there's nothing magic about it.

I see.

list-packages gets the core Emacs packages from the installed directory
on my disk; that's from the Emacs release I installed. It gets ELPA
packages (and others) from the web, as specified in `package-archives'.

I suppose it would be possible to add the Emacs git (or bzr) repository
to package-archives; it's not there by default.

However, that would be problematic when core Emacs packages are changed
to reflect other core changes that are not in the current Emacs release;
users of that package would have to be careful to not upgrade. That
_might_ be handled by the dependency mechanism; the new version of the
core package should depend on the new version of Emacs, which
list-packages should know is not available.

There is a similar problem with ELPA packages, of course; but it is
easier to provide backwards portability solutions there (these are
usually discouraged in the Emacs trunk, which I think is a good policy).

So it comes down to how closely coupled the package is to the Emacs
core; if the coupling is loose, an ELPA package makes more sense.

-- 
-- Stephe



reply via email to

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