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: Tue, 15 Dec 2020 22:29:07 +0200 Message-ID: <83eejqak4s.fsf@gnu.org> References: <86a6ugnopl.fsf@stephe-leake.org> <83im94b17m.fsf@gnu.org> <834kknatxs.fsf@gnu.org> <83r1nqaph6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26710"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stephen_leake@stephe-leake.org, daniele@grinta.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 15 21:30:04 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 1kpGxP-0006oK-Nq for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Dec 2020 21:30:03 +0100 Original-Received: from localhost ([::1]:49338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpGxO-0006dS-On for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Dec 2020 15:30:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpGwr-0006Cr-94 for emacs-devel@gnu.org; Tue, 15 Dec 2020 15:29:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58845) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpGwp-0004mu-LR; Tue, 15 Dec 2020 15:29:27 -0500 Original-Received: from [176.228.60.248] (port=4983 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kpGwc-00087E-Nv; Tue, 15 Dec 2020 15:29:26 -0500 In-Reply-To: (message from Stefan Monnier on Tue, 15 Dec 2020 15:11:47 -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:260924 Archived-At: > From: Stefan Monnier > Cc: daniele@grinta.net, stephen_leake@stephe-leake.org, emacs-devel@gnu.org > Date: Tue, 15 Dec 2020 15:11:47 -0500 > > > Doesn't package.el install stuff under ~/.emacs.d/elpa/ ? > > If so, what happens with installed Lisp files under /usr/share/ ? > > The way package.el works, is that it collects all the packages it can > find installed locally under `package-directory-list`. This list can > contain many different versions of the same package. `package-activate` > then choose which ones of those packages to activate, under the > constraint that only one version of each package can be activated in > a given session (and under the additional constraints setup by the user > in `package-load-list`). > > This was designed so that a sysadmin can install a bunch of packages and > users can then make use of them without being stuck using all those the > sysadmin has chosen to install, not stuck with the version that the > sysadmin installed. > > If the Emacs tarball bundles packages, it would basically act as "a > sysadmin" in this regard. Users could still override that set of > bundled packages with older/newer versions or even choose not to > activate some of the bundled packages (tho I'd hope that the packages we > choose to bundle are clean enough that this would never be useful, just > like it's not considered useful for the user to be able to remove stuff > from lisp/loaddefs.el). Are you talking about something that already works, or about something that _could_ work, after some changes? If the former, then where's the code to support it? > > And what about the relation between the version in ELPA and the > > branches/versions of Emacs in the Emacs repository? IOW, how will a > > package that needs Emacs version N+1 work with Emacs version N? > > What about it? The packages bundled with Emacs-N+1 would *not* be in > the `package-directory-list` of Emacs-N (and vice-versa), so there'd be > no particular issue at stake here. That won't fly, because usually some previous version of that same package did work with Emacs-N. And since packages don't usually have a stable branch and a development branch, how to bundle them and how to upgrade them later becomes a mess. Some of that was discussed in this thread, for example: https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01000.html > > Bottom line, I feel that there's some kind of "trust us, it will be > > fine" attitude here, whereas I would expect careful investigation of > > all these aspects and some description of the procedures. > > AFAIK all the investigation that can be done has been done. I don't > doubt that there will be issues to resolve, but I don't think we will > find them before we actually start doing it. We are being asked to "start doing it" right now in emacs-27. I'm sorry, but this is not a serious suggestion, given the state of the affairs and the number of issues for which we just think we know how to solve them. Like that pianist that knows how to play the piano, but has never tried. And what does it mean "start doing it", really? We prepare a tarball only once we start a pretest, by which time it's too late to experiment with untested machinery. And doing that on master makes no sense, because there are no tarballs. So here's one more issue for us: how can we ever get this stuff to maturity if we cannot test-drive it until it is too late?