From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: decision on moving core packages to ELPA; also move to obsolete? Date: Wed, 16 Dec 2020 19:53:14 +0200 Message-ID: <83pn398wol.fsf@gnu.org> References: <86a6ugnopl.fsf@stephe-leake.org> <83im94b17m.fsf@gnu.org> <834kknatxs.fsf@gnu.org> <83sg86apqb.fsf@gnu.org> <865z52oqfp.fsf@stephe-leake.org> <86wnxinbnx.fsf@stephe-leake.org> <83o8iuann7.fsf@gnu.org> <83h7omakyw.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4211"; mail-complaints-to="usenet@ciao.gmane.io" Cc: daniele@grinta.net, stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 16 18:54:16 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpb0C-00011K-6c for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 18:54:16 +0100 Original-Received: from localhost ([::1]:53336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpb0B-0006lW-7Z for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 12:54:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpazK-0005y6-Em for emacs-devel@gnu.org; Wed, 16 Dec 2020 12:53:22 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59614) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpazH-00052O-Ml; Wed, 16 Dec 2020 12:53:19 -0500 Original-Received: from [176.228.60.248] (port=3704 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kpazH-0002tk-1A; Wed, 16 Dec 2020 12:53:19 -0500 In-Reply-To: (message from Stefan Monnier on Tue, 15 Dec 2020 17:01:42 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261021 Archived-At: > From: Stefan Monnier > 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.