[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: |
Eli Zaretskii |
Subject: |
Re: decision on moving core packages to ELPA; also move to obsolete? |
Date: |
Wed, 16 Dec 2020 19:53:14 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen_leake@stephe-leake.org, daniele@grinta.net, emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 17:01:42 -0500
>
> You tell me how you want it to work, and we'll write the support
> code accordingly.
I'm not sure mine is the only voice we should listen to, but I try to
outline something below.
> E.g. one way this could work is as follows:
>
> Currently every GNU ELPA package has a corresponding branch
> `externals/[PKGNAME]` in `elpa.git` where the source code is kept.
> We could add to elpa.git a bunch of branches `emacs/[PKGNAME]` which
> keep the version of the code we want to include in the next release
> of Emacs.
That would have to be emacs-NN/PKGNAME, where NN is the major Emacs
version.
> Those branches can be updated whenever we or the package's
> maintainer deems appropriate.
Which would mean having procedures in place for those maintainers to
make such branches as part of preparing a release and the pretest.
> Our tarball-builder-script would then grab the bundled packages's code
> from those branches.
I hope this could be much more seamless, see below.
> E.g. we'll have code in the tarball that's not present in a Git
> checkout, which means that people who work from the Git may
> be disappointed.
That's something we should resolve as part of the ELPA integration.
> I don't see any need to "solve" or discuss those issues before we can
> bundle packages.
I don't agree. We should have a reasonably comprehensive solution in
place, and it cannot just include building the tarball. The solution
doesn't have to be perfect, but it should exist for all of the aspects
I mention below, and maybe some more.
> > We need to go over those issues and solve them before we can seriously
> > talk about unbundling ada-mode or any other package.
>
> I'm not talking about unbundling anything here. I'm talking about
> bundling *additional* packages currently not distributed with Emacs.
> [ BTW, ada-mode is already "unbundled", AFAIK. ]
That was a mistake, and this thread started as an attempt to fix it.
> Obviously, the ability to bundle GNU ELPA packages might allow/encourage
> moving some packages from Emacs to GNU ELPA. It's indeed one of the
> longer term benefits that makes bundling interesting, but in the short
> term (i.e. Emacs-28), this is not on the table AFAIK.
AFAICT, it depends whom you are asking.
Here's what I think we should have working to start bundling ELPA
packages:
1. Git
We need to have the bundled ELPA packages in the Emacs Git tree,
and we should have an easy way of cloning/updating from upstream
in a way that will also update the packages from ELPA.
This should be set up in a way that both master and the release
branch get updates from designated branches of the ELPA package's
repository. This way, working with the Emacs Git repository will
remain almost unchanged. Building Emacs from Git, something I at
least do all the time, will also remain unchanged.
(Yes, "git submodule" commands can do most or all of the above,
and I think we should use them.)
Package maintainers will have to provide designated branches with
uniform names that will serve for fetching the package into each
branch of the Emacs repository.
One thing that will constitute a change is that each bundled
package will need to have its own subdirectory of lisp/, even if
the package is just one .el file. Not a catastrophe, I think.
Another aspect to consider is the auxiliary files -- README,
documentation, etc. -- which come with the package. We will need
some changes in the Makefile's to have the products in the right
places.
2. Tarball
Given that the Git repository will be ready due to the above, the
procedures for creating a tarball will also remain almost
unchanged.
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.
I hope we can discuss each of these aspects (and others, if I missed
something), and this time actually come to a consensus and implement
that.
- 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?, Stephen Leake, 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?, 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 <=
- 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?, 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