[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
- Re: Adding packages to ELPA, (continued)
- Re: Adding packages to ELPA, Stefan Monnier, 2014/09/19
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/19
- Re: Adding packages to ELPA, Phillip Lord, 2014/09/19
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/19
- Re: Adding packages to ELPA, Richard Stallman, 2014/09/19
- Re: Adding packages to ELPA, Stefan Monnier, 2014/09/19
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/19
- Re: Adding packages to ELPA, Stefan Monnier, 2014/09/19
- Re: Adding packages to ELPA, Stephen Leake, 2014/09/20
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/20
- Re: Adding packages to ELPA,
Stephen Leake <=
- Re: Adding packages to ELPA, Stefan Monnier, 2014/09/20
- Re: Adding packages to ELPA, Stephen Leake, 2014/09/20
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/20
- Re: Adding packages to ELPA, Phillip Lord, 2014/09/22
- Re: Adding packages to ELPA, Eli Zaretskii, 2014/09/22
- Re: SP? {Spam?} Re: Adding packages to ELPA, Phillip Lord, 2014/09/22
- Re: Adding packages to ELPA, Richard Stallman, 2014/09/19
- Re: Adding packages to ELPA, Richard Stallman, 2014/09/19
- Re: Emacs Lisp's future, Daniel Colascione, 2014/09/17
Re: Emacs Lisp's future, Eric Brown, 2014/09/17