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, 20 Apr 2023 17:25:49 +0300 Message-ID: <838rem636a.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <83pm7z7nkc.fsf@gnu.org> <4b63ef62-5e1c-3dcf-ec7b-06b69e79133b@gutov.dev> <83o7nj7mfn.fsf@gnu.org> <556e0fbb-215e-c11d-0e8b-73e97441abbb@gutov.dev> <83pm7y6fdo.fsf@gnu.org> <47140c27-ba63-ca7b-8b9e-cc38a6f9a866@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38067"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 20 16:26:39 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 1ppVF8-0009ha-4f for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Apr 2023 16:26:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppVEa-0007Xk-S1; Thu, 20 Apr 2023 10:26:04 -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 1ppVEZ-0007X0-9N for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 10:26: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 1ppVEZ-0007Va-0q for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 10:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppVEY-0000u8-IZ for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 10:26: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, 20 Apr 2023 14:26: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.16820007533453 (code B ref 62720); Thu, 20 Apr 2023 14:26:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 20 Apr 2023 14:25:53 +0000 Original-Received: from localhost ([127.0.0.1]:38464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppVEO-0000tc-9Q for submit@debbugs.gnu.org; Thu, 20 Apr 2023 10:25:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppVEM-0000tN-1E for 62720@debbugs.gnu.org; Thu, 20 Apr 2023 10:25:50 -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 1ppVEA-0007Kq-JQ; Thu, 20 Apr 2023 10:25:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=KZ0MYvwk7s3o0p7tgfeaHG8lP5TGudwKMPKRHUQMYP8=; b=oaWshfN0lZtWC5S/ozV5 e9BqDNZYjzLlpa3x7V5oE1ijXq/yrKGlc4pZ6pWwaI0110kahiJVJUoSu8cg69xfbtuAOy5g//JnC r9O2SpW9c0x/boBiQe9c3YE0ytWyRNi3+unXntOzpmx0rm33hoT0phjpdpN6SKUJ41gfRZh91cBeG xurX3MJL8vxltwu48+YGRmGkciqHNNM2RRaBtQQB8tCWqvtaw7iKLZ213eAghFR3sTpvPcez/nyR4 3um2BE+NdYbBqbPa/Xy47LqnEgzWDdVuhFk4exhNhTsSnPwG8Qytozq9VvmIDi4E+1wKgjZi2Gzn0 BTuEn7OEXP3tlg==; 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 1ppVE7-0003wI-Q7; Thu, 20 Apr 2023 10:25:37 -0400 In-Reply-To: <47140c27-ba63-ca7b-8b9e-cc38a6f9a866@gutov.dev> (message from Dmitry Gutov on Thu, 20 Apr 2023 16:39:20 +0300) 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:260337 Archived-At: > Date: Thu, 20 Apr 2023 16:39:20 +0300 > Cc: joaotavora@gmail.com, jporterbugs@gmail.com, 62720@debbugs.gnu.org, > philipk@posteo.net, monnier@iro.umontreal.ca, larsi@gnus.org > From: Dmitry Gutov > > > So before we discuss solutions, we need a full and detailed > > description of the problems to solve. If someone can do the footwork > > of collecting this information and posting it here, please do, and > > TIA. > > I think I have made a fair attempt at this, though. Here's an update: Thanks. What I miss in this description is something a bit higher-level: the list of all the ways/commands/methods people use to install and upgrade the packages. We must have this list before our eyes to make sure we review all the behaviors related to these activities, if we want them all to eventually behave consistently. E.g., you don't mention any commands invoked from the package menu. > - package-upgrade (nee package-update) doesn't upgrade builtin packages > that never been upgraded before. It's a bug. Hopefully not too hard to fix. I'm okay with adding the same prefix argument to package-upgrade, which would then allow upgrading a built-in package. IOW, a change similar to what we did in package-install -- provided that the change is safe enough to go into Emacs 29. But note that AFAIU there's a relatively easy workaround for this: install the later version of the package manually, just once. > - package-menu-mark-upgrades and package-update-all don't upgrade them > either. That's not necessarily a bug, but a problem nevertheless. A new > user option could help. A very relevant question is: can this wait till Emacs 30? > - The current fix (commit 580d8278c5f48) is not comprehensive WRT to > Joao's scenario because use-package-ensure-elpa short-circuits when it > find that the package is installed ('package-installed-p' returns t). So > (use-package eglot :ensure t) does not upgrade Eglot even when > package-install-upgrade-built-in is t. I don't think (use-package eglot :ensure t) should automatically upgrade built-in packages. We could make it do that if package-install-upgrade-built-in is non-nil -- again, if such a change could be safe enough. If not, then the same workaround as for package-upgrade would do here, I suppose? > - package-install-upgrade-built-in is not nuanced: if we suggest the > users to set it to t, that can result in making _all_ builtin packages > upgradable with 'package-install'. It should be set to t only by users who indeed want all built-in packages to be updated. That's why the default is nil. > Whereas I think we originally only wanted that for Eglot and maybe > for use-package. "We" never did want that. João did, for obvious reasons, but that was never my intent. The issue is indeed more general: what should package-install and package.el in general do with built-in packages for which a newer version is on ELPA? We don't yet know the answer to that, and no hope of obtaining one before Emacs 29.1 is released (barring any calamities). > For this and other minor reasons I would suggest reverting > 580d8278c5f48. Not going to happen, not unless someone comes up with a better solution that is much better and still safe enough. Personally, I don't believe such a solution exists, since we don't really know the answer to the above question. > But I suppose we could also try to make it more granular (e.g. turn > the boolean option into a list). I'm not sure it's a good direction > overall, however. I don't think we should go in this direction, precisely because we don't know it's a good one. > - According to Jim P., package pinning doesn't work for builtin packages > either. Which could be a decent solution as well, e.g. putting something > like this in the docs: (use-package eglot :ensure t :pin gnu) if the > users want the Eglot version from ELPA -- and this form might even be > compatible with Emacs 28. I'm not sure how difficult it would be to fix > package pinning, however. As long as this is optional behavior (and AFAIU it is), I won't object, but again, provided that the addition of this will not touch any other code in unsafe ways. > The reasons for me to be hopeful are: > > - The functions are propose to fix are "leaves": those that are supposed > to be used interactively, without (many) known callers in-tree. E.g. > fixing package-update-all shouldn't affect some other part of Emacs as > much as changing package-install could. Experience until now in this thread indicates otherwise: almost every suggested change touched low-level code with many callers. It isn't an accident that arriving at what was finally installed took so many iterations for such a simple change.