From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 16:39:20 +0300 Message-ID: <47140c27-ba63-ca7b-8b9e-cc38a6f9a866@gutov.dev> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34886"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 20 15:40:37 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 1ppUWa-0008pq-9u for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Apr 2023 15:40:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppUW4-0003l4-Fk; Thu, 20 Apr 2023 09:40: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 1ppUW2-0003kv-Te for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:40:02 -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 1ppUW2-0005PS-Jn for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppUW1-0007ZM-Vi for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 09:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Apr 2023 13:40:01 +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.168199797529053 (code B ref 62720); Thu, 20 Apr 2023 13:40:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 20 Apr 2023 13:39:35 +0000 Original-Received: from localhost ([127.0.0.1]:36846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppUVa-0007YW-V7 for submit@debbugs.gnu.org; Thu, 20 Apr 2023 09:39:35 -0400 Original-Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]:36379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppUVZ-0007YH-0x for 62720@debbugs.gnu.org; Thu, 20 Apr 2023 09:39:33 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 61E892B06836; Thu, 20 Apr 2023 09:39:26 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 20 Apr 2023 09:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1681997964; x=1682001564; bh=xSOpXv7o5Eadl9WcySUwhTN8LAMCo5eswVK xOi1gsj8=; b=D/eu/vAMhIwfhOLkCjSmM4hbDA6JgZAxULmvHo29Ciz0dsNEPyA Y+fGqKZ0tUwPZ2uYKAMnRtYbCx0Hy2JK/KyskU1NfjAahJhbyYxGVhMSAsomB9Ik sup+sCHQNuuDRPvmSssvQWYwMOqHmzTNfLUXdjXYCU5HLfWT3SwOYl2+hA6MR2j+ SwdZZD+yT4xVcXFXltI+85r3ndG8tMmzMUzK8AUvAZ8uTb79sc/cOa7HHDi81GXU UWPdbKkmr4ZAvWdQWcsCY39WrIZ6rL7LPGqW4uZcCG141jDQkZRgF2IKmkGa+Jyf cgrTDh6rjWNRo1O2rVjVRhvlhLm9E9MMWzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681997964; x=1682001564; bh=xSOpXv7o5Eadl9WcySUwhTN8LAMCo5eswVK xOi1gsj8=; b=c6bb2UkRd3U+fMuKuSIJxjbNYZKzp/IQA4TzTebusNO362iYnLv NX4uM9Cn02jpCPB8fjZU/sJzKRA7tZOF1rMPExJmYzhUlKE+8Xr/C80RV6ztWI0g J3lU01QpUPRM3N7LNcqP4DaPE1p5TRyKM6Q41Zkq7hNqV1NVmrY3hg/STUNeSgCo /jjA/w2K38+cZX/wGPdkFzY82zgHfujOGewqtozwwo0tYtRnNim2YD+UMg4OeScU ++ZPD3AJ0bwZ4fylfgcxmgbtlNNnUz9C0GqMAjASYC7q0lqhSZa4ybD5Prap83KG pZW8CPKRtM5aNekOKuHmt2OW0wKgsFg+96Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtvddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Apr 2023 09:39:22 -0400 (EDT) Content-Language: en-US In-Reply-To: <83pm7y6fdo.fsf@gnu.org> 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:260332 Archived-At: On 20/04/2023 13:02, Eli Zaretskii wrote: >> Date: Thu, 20 Apr 2023 01:06:10 +0300 >> Cc: Eli Zaretskii , arne_bab@web.de, jporterbugs@gmail.com, >> emacs-devel >> From: Dmitry Gutov >> >> OK then, I think have to re-evaluate my position on this. Previously, I >> guess, I made some hasty conclusions from how the discussion went on >> without refreshing the exact details about package.el and use-package >> (the latter I never knew to begin with). Apologies. >> >> Eli, let me know if we should take this back to the bug tracker instead. > > I've moved this back to the bug-tracker. Please post all further > replies about this particular issue, i.e. updating of built-in > packages with package.el, to this bug and not to emacs-devel. Noted. >> So I would suggest to focus on functions that don't work as intended. >> Namely: >> >> - Add a user option for the list of builtin packages which would be >> upgraded automatically by 'package-menu-mark-upgrades' and 'M-x >> package-upgrade-all' (nee package-update-all). Maybe make it nil by >> default, or maybe add 'eglot' to it. I don't have a strong opinion. >> >> - Fix 'M-x package-upgrade' (nee package-update) to suggest Eglot as one >> of the options and actually perform the upgrade. That shouldn't require >> changes to 'package-install' because, as we already know, the user can >> already install a newer version of Eglot using the 'list-packages' menu >> (and picking the exact version manually). That execution path is going >> to go through 'package-install' as well, so it must be suitable already. >> >> - Revert 580d8278c5f48 because it creates odd semantics (upgrading >> certain packages that are already installed but not others) and it >> doesn't solve the issue with (use-package 'eglot :ensure t) anyway. We >> could keep it, but seems like a half-measure that didn't make anyone >> happy anyway. OTOH, it could minimize the rewrites of CI scripts. > > I don't think we are ready to make any new decisions in this matter. > I think we don't even have a comprehensive and detailed picture of the > problems with updating/upgrading built-in packages in Emacs 29. > People are still discovering facts and subtleties of various > package.el commands and features, and are still arguing what exactly > happens in this or that scenario. True. > 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: - 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. - 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. - Fixing package-update should also obviate the need for eglot-update. Though perhaps the latter could still be useful as a single entry point to recommend to both users of Emacs 28 and 29+. - 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. - 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'. Whereas I think we originally only wanted that for Eglot and maybe for use-package. For this and other minor reasons I would suggest reverting 580d8278c5f48. 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. - 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. I haven't spent as much time on this bug as some others here, though, so corrections and additions are welcome. > I will say up front that, given what I already read here and in the > related thread on emacs-devel, there seem to be too many > inconsistencies and dark corners in this, in particular when built-in > packages are involved. We will probably be unable to solve them in > time for Emacs 29.1, certainly not all of them. So don't raise your > expectations too high. 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. - I imagine the diffs will be rather short. I haven't tried to take a stab at this yet, though, and if somebody wants to take the initiative, they're very welcome. The reasons for me to be less hopeful: - We seem to be unable to come to any agreement here. :-D Joao's approval for the above list would go a long way.