[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: decision on moving core packages to ELPA; also move to obsolete?
From: |
Stefan Monnier |
Subject: |
Re: decision on moving core packages to ELPA; also move to obsolete? |
Date: |
Wed, 16 Dec 2020 13:35:01 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> Here's what I think we should have working to start bundling ELPA
> packages:
Then I think the "git submodule" approach proposed earlier by Andrea
is the better solution: every ELPA package we want to include will have
a branch in `emacs.git` (e.g. with name `elpa/[PKGNAME]`) and in Emacs's
`master` branch we will add git submodules which refer to (specific
revisions on) those branches.
This way a Git checkout can also contain those ELPA packages. We can
easily control which version of a package is included into any given
version of Emacs because git submodules refer to specific revisions.
And those `elpa/[PKGNAME]` branches can easily kept in sync with
the corresponding branches in `elpa.git` (and upstream if applicable).
> 3. Users
>
> We need a clear picture of how this Emacs will be installed and
> used, both when installed from a distro and when built locally
> from the source tarball. Maybe there's nothing to discuss here,
> but I at least don't yet have such a clear picture. It should be
> possible to install, upgrade, and downgrade such packages, as much
> as possible using the same package.el commands as for unbundled
> packages. As a minimum, AFAIU we will need to provide a directory
> in the tarball/installation that will have the same role as
> ~/.emacs.d/elpa/, because a tarball cannot possibly install files
> in the users' home directories.
We will place the submodules under some `elpa` subdirectory of our
choice after which we simply have to add that directory to the default
value of `package-directory-list`.
Stefan
- Re: decision on moving core packages to ELPA; also move to obsolete?, (continued)
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Dmitry Gutov, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Dmitry Gutov, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Tests in core depending on GNU ELPA packages (was: decision on moving core packages to ELPA; also move to obsolete?), Thomas Fitzsimmons, 2020/12/15
- Re: Tests in core depending on GNU ELPA packages, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?,
Stefan Monnier <=
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stephen Leake, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stephen Leake, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15