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.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Thu, 13 Apr 2023 08:49:46 +0300 Message-ID: <83bkjs5o1x.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <87ile2n0kn.fsf@gmail.com> <83v8i2abqi.fsf@gnu.org> <87wn2ilgx7.fsf@gmail.com> <83a5ze9uc1.fsf@gnu.org> <831qkq9rpy.fsf@gnu.org> <83pm898xb9.fsf@gnu.org> <87h6tlleg0.fsf@gmail.com> <8335558qc7.fsf@gnu.org> <83sfd5761f.fsf@gnu.org> <87zg7djrgr.fsf@gmail.com> <83o7nt73za.fsf@gnu.org> <83mt3d73c2.fsf@gnu.org> <87r0sptinq.fsf@posteo.net> <83jzyh706c.fsf@gnu.org> <875ya1tdwf.fsf@posteo.net> <83edop6sdy.fsf@gnu.org> <87pm88kgj9.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40582"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 62720@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 07:50:28 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pmpqm-000AJp-Fp for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 07:50:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmpqQ-0006O6-Fx; Thu, 13 Apr 2023 01:50:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmpqN-0006Nl-Ac for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 01:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pmpqN-0005u8-0h for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 01:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmpqM-0001ks-FR for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 01:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 05:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.16813649546672 (code B ref 62720); Thu, 13 Apr 2023 05:50:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 13 Apr 2023 05:49:14 +0000 Original-Received: from localhost ([127.0.0.1]:42381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmppZ-0001jX-L8 for submit@debbugs.gnu.org; Thu, 13 Apr 2023 01:49:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmppU-0001iy-6O for 62720@debbugs.gnu.org; Thu, 13 Apr 2023 01:49:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmppN-0005nk-7q; Thu, 13 Apr 2023 01:49:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tOgXcvfK8h2jG9HiL2Tq7K7k5J0blVDHP9ctT/ubEV4=; b=YlHHhc5JP+Bb NxJLMQzE6pPqw5OfFslNsb2P4LjzWmi2tlf1CsGVpsKXI3d5UwPZg4LmXf8AEqAH4JbCC5q+UBOGf OiZwFeJEPnfMopBRnFoqgc0lnXQ8MFSzzlOOhAMT3ZVvqUge1XL+VJOgsYRQajNvAEhCVp8FNrSnI sgDBcZQ9A3xoojzvoQ5OsnzYWLecuzmWh7d8P3MZI6sMfsVDqarx0ie5ACoaJX16r9lw8R5Ir+A51 wGSpHegZPj6b6QcxuuZZo38B5RMcjaDcsVgMLqZpPa9fstaRJ2Fd8ttk99zN5AVKks/z5yBllxnBs qEcOQWNb9RlOHp4RvcImtA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmppM-0001J9-DT; Thu, 13 Apr 2023 01:49:00 -0400 In-Reply-To: <87pm88kgj9.fsf@posteo.net> (message from Philip Kaludercic on Wed, 12 Apr 2023 20:10:50 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259835 Archived-At: > From: Philip Kaludercic > Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 62720@debbugs.gnu.org, > larsi@gnus.org > Date: Wed, 12 Apr 2023 20:10:50 +0000 > > >> > And I thought we all agreed built-in packages need special treatment > >> > anyway, didn't we? Then why having a separate command is not a > >> > natural next step? > >> > >> I don't necessarily agree that "special treatment" requires a separate > >> command. > > > > Even if you don't agree with that in general, having a separate > > command would allow us to install that command on emacs-29 without any > > fears. So that alone is a significant advantage, even if the rest are > > not yet agreed upon. > > Would this be a permanent thing, or would the command be deprecated by > emacs-30? I get the need under the circumstances, but it doesn't seem > like the best solution if we were to set aside release-concerns. We could keep the separate command on master as well, at least until it is obvious that a special command is not needed in any use case. The time to revisit this is when we take some practical steps towards removing from emacs.git packages that are on ELPA and figuring out how to bundle them with a release tarball and how to let users upgrade them after they install a released Emacs. It could be that when we implement all that, there will be some aspects of upgrading core packages that will benefit from having a separate command. If we find this is not needed, we can deprecate the command at that time. Mind you, the command I have in mind is one that will allow upgrading _only_ built-in packages, i.e. it will not deal with the packages that don't come with an Emacs tarball. > >> I think it is wrong the assume that an built-in package should > >> automatically be updated to a ELPA package whenever possible. > > > > This seems to be an argument in favor of a separate command? Or what > > did you mean by that, and how is it related to the issue at hand? > > I don't think package-update should switch from a built-in package to a > package that was installed from ELPA. The user should at least once > commit to the switch (be it with a separate command or package-install). I tend to agree. Although, once again, we should revisit this when core packages are no longer in emacs.git. Taking a perhaps somewhat different analogy of updating my smartphone, there's no particular difference between updating a "built-in" app, one that is part of the smartphone's system components and came with it OOTB, and updating any other app, including those I installed myself. I think the same is true for updating system components and applications from any modern distro, isn't it? So this is yet to be decided, but for now we can use this more conservative policy. > > . install your changes on master only, and leave the problem of > > updating a core package unsolved in Emacs 29 (with the workaround > > mentioned in the beginning of this bug's discussion available to > > alleviate the problem to some extent) > > . come up with safer changes for package-install that could be > > installed on emacs-29 > > . add a new command for updating a core package, which can then be > > safely installed on emacs-29 > > > > The last 2 alternatives can be for emacs-29 only, whereas on master we > > install your proposed change (or something else). > > I would like to investigate option 2, but if nothing is found we can > fall back to 3. But even if there are issues in this case, I don't > consider the matter in general to be that drastic. If all Joao wants is > to avoid confusion, we can also improve the error message that > `package-install' generates when it says that a package ins already > installed. Yes, I think if we go with the modified package-install or package-update, then invoking them in a way that doesn't update built-in packages should reflect that in the error message, and also tell how to invoke them to be able to upgrade a built-in package. > >> One point that might be deliberated is that this means all built-in > >> dependencies are also installed, even if these are not strictly > >> necessary. It shouldn't matter that much, since most users would > >> upgrade them eventually, but worth mentioning I guess? > > > > That just confirms my fears that we are opening a Pandora's box. We > > have no idea what this will do, and no time to test the results. > > Unintended consequences are abundant. We must draw any such > > consequences to the absolute minimum, at least the way the commands > > work by default. Even if the result is less than elegant. > > Intuitively I would want to argue that this change has an upper-bound to > how much harm it could do, but as I cannot prove it in any way I'll > rather not assert that the point. There is, of course, an upper bound. But I don't think we know how high that is at this time. Bitter experience has taught me that we are not very good in predicting that. > >> + (and (not (assq (cond > >> + ((package-desc-p package) > >> + (package-desc-name package)) > >> + ((stringp package) (intern package)) > >> + ((symbolp package) package) > >> + ((error "Unknown package format: %S" package))) > >> + (package--alist))) > >> + (package-built-in-p package))) > > > > Why do we need all these conditions, where we didn't need them in the > > current code? > > Practically speaking these conditions are not necessary, I just added it > in case there was the need to use the function elsewhere at some point. Then maybe these conditions should be only on master. > > Also, package-alist is documented as "alist of all packages available > > for activation", so it is not clear how the fact that assq returns nil > > is evidence that "the user has not installed a more recent version". > > Looking at what package--alist and package-load-all-descriptors do, it > > looks like they just collect packages that were downloaded into the > > relevant directories? Is that enough to consider any package not in > > the list to be "not installed"? > > The point is that package.el will add all packages it manages (ie. are > "available to activation") to package-alist. Built-in/core packages are > not managed by package.el, but just "acknowledged" via > `package--builtins'. So this looks like a safe assumption to me. These subtleties should ideally be documented somewhere in package.el. Without being aware of all that, it is hard to read the code of package.el and understand what it does and why, and the names and doc strings of the relevant symbols in most cases don't help, as they all use vague and too-broad words to describe their purpose and effects. > > And what about the "more recent > > version" condition -- this doesn't seem to be tested anywhere in > > package--alist? > > You are right, but this is a misphrasing. How so? what should be said instead?