From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode Date: Tue, 23 Jan 2024 14:34:47 -0800 Message-ID: <87le8fisqg.fsf__41038.7640165695$1706049393$gmane$org@neverwas.me> References: <877ck14dt4.fsf@neverwas.me> <87o7dcm718.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, 68660@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 23 23:36:26 2024 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 1rSPNZ-0002mM-Hv for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Jan 2024 23:36:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSPN9-0003WW-Ur; Tue, 23 Jan 2024 17:35:59 -0500 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 1rSPN7-0003WG-Vr for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2024 17:35:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rSPN7-0002bM-Nm for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2024 17:35:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rSPNC-0005IY-C0 for bug-gnu-emacs@gnu.org; Tue, 23 Jan 2024 17:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jan 2024 22:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68660 X-GNU-PR-Package: emacs Original-Received: via spool by 68660-submit@debbugs.gnu.org id=B68660.170604930820273 (code B ref 68660); Tue, 23 Jan 2024 22:36:02 +0000 Original-Received: (at 68660) by debbugs.gnu.org; 23 Jan 2024 22:35:08 +0000 Original-Received: from localhost ([127.0.0.1]:44108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSPMJ-0005Gu-6V for submit@debbugs.gnu.org; Tue, 23 Jan 2024 17:35:07 -0500 Original-Received: from mail-108-mta221.mxroute.com ([136.175.108.221]:39129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSPMG-0005Gj-7j for 68660@debbugs.gnu.org; Tue, 23 Jan 2024 17:35:06 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta221.mxroute.com (ZoneMTA) with ESMTPSA id 18d387659b30003727.001 for <68660@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 23 Jan 2024 22:34:56 +0000 X-Zone-Loop: 96c2b3e6d77fe4777de5ab9d7478a3892abafcb5b6d1 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JF/0yl+yFz1zbaXAkbKV2Yrnj5Xxt0tbKZOivsgRzJI=; b=STSfKmwtTP1xGWce41Ux6Tywx8 qBvsfIIw5Pmb/oJPx13Tmg/ZjrDBK8lo5NkcJSO3h7kShe4M5DMN+c+MmHYX8xstcQb6uLUYo7uke QdqA8dhrpV5rOdFN9i3Csln3walsW9sWU/X+Gm4h5yV3UQg5r+ifg9zGyQkXE5CGd9pCL+Wkab5ZI +wY0rO6At3NMj5NLPthzBmtSLVhKX3wNfiZ0d6Zoe24YTnR2RnJ/aiaD2gLM9JiEoB24vqXR5PQ6i g/Gk0HOpZAXI85cFNJovx2mmrSDHjw6gBv5TfT0hdnyIpyoYVorxQkqjQg7iUIyW/BkVzCbAJBqk+ QDKBVHcw==; In-Reply-To: (Stefan Monnier's message of "Tue, 23 Jan 2024 14:48:41 -0500") X-Authenticated-Id: masked@neverwas.me 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:278749 Archived-At: Hi Stefan, Stefan Monnier writes: >> Hm, I'm starting to suspect this perceived "breakage" may in fact be >> intentional (i.e., a "schema evolution"), at least on the /devel >> endpoint, given it seems to be reflected in the disparity between >> >> ;; /devel/archive-contents >> (:maintainer ("Bob Weiner" . "rsw@gnu.org") >> ("Mats Lidell" . "matsl@gnu.org")) >> >> and >> >> ;; /packages/archive-contents >> (:maintainer "Bob Weiner , Mats Lidell" >> . "matsl@gnu.org") > > That just depends on when the package was built (i.e. before or after > `elpa.gnu.org`s Emacs was upgraded from Emacs-27 to Emacs-28). Not sure if this is relevant, but it seems `package-archive-version' is 1 on both sides of this divide. Should it maybe have been incremented? [...] > >> Assuming this isn't a red herring, will this perceived dichotomy hold >> going forward? That is, can we count on releases at the /packages >> endpoint being of the improper-list variety and not the alist variety >> for the foreseeable future? > > No. Perhaps GNU ELPA would consider versioned endpoints serving the same resources in older formats, e.g., /package/v1 /devel/v1 >> If so, then I guess this bug is much ado about nothing and can be >> closed, since ERC 5.6+ will be installable on 27+ in the manner >> recommended in our docs. > > Its installable via `package-install`, but not from the > `package-menu-describe-package` because of this bug in that command. This indeed works interactively on Emacs 29. Thanks. However, ERC also supports versions 27 and 28. What's the recommended way for folks to upgrade on those Emacsen? The least gruesome thing I could conjure up is (package-install (car (alist-get 'erc package-archive-contents))) But that's still a rather unfriendly incantation, IMO. Also, pardon my ignorance here, but it was my understanding that M-x list-packages RET is meant to be the de facto entry point for baseline upgrade functionality in Emacs. If you'll recall, during the lead up to Emacs 29's release, various discussions unfolded in and around bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot And throughout these, the following method held firm as a surefire way for upgrading a :core package: "It's not impossible to upgrade in Emacs 29, of course. The only way I know is to M-x package-list-packages, find Eglot 1.14 in the list, mark it with 'i' and confirm installation with 'x'. But it is very awkward." [1] Despite being "awkward," this method was acknowledged as reliable by multiple parties who were often otherwise at odds with one another: "OTOH, the workaround you described in [62720#5 [1]] doesn't sound too awful to me, given that this problem exists for a while and is not specific to Eglot." [2] "So we have the following alternatives for the way forward: [...] 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)" [3] "The official way of switching from built-in packages to ELPA should still be to use the package menu." [4] "But selecting the package with I and then installing it will "update" it" [5] "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)" [6] "Whereas one can always upgrade a built-in package using 'i' (package-menu-mark-install) in the list-packages menu" [7] "To manually execute an upgrade of one package, one needs to both mark the new version for installation (after first scrolling down the list to find it), and mark the current version for deletion. This is what currently an upgrade consists of." [8] "We do. We have commands for upgrading, both in "list-packages", and used interactively. Which do the thing of installing the new version and removing the old one. Which is what upgrading means in various tools, e.g. 'apt'." [9] "The bug#62720, reported by me, listed the only workaround that works identically in Emacs 2*. Just go to the package menu and press 'I' on the package you want to install. Boom, there go the ancient safeguards against updating builtin packages." [a] Thus, because this method, however unfashionable, also seemed the only one compatible with older Emacsen [b], ERC's documentation adopted it as its recommended means of upgrading: To upgrade, run =E2=80=98M-x list-packages =E2=80=99. In the =E2=80= =98*Packages*=E2=80=99 (=E2=80=98package-menu-mode=E2=80=99) buffer, click the =E2=80=98erc=E2= =80=99 package link for the desired version. If unsure, or if the version column is too narrow to tell, try the bottom-most candidate. In the resulting =E2=80=98help-mode= =E2=80=99 buffer, confirm the version and click =E2=80=98Install=E2=80=99. [c] And this adoption was made known to the current Emacs maintainers at the time [d]. Consequently, the language above was indelibly seared into the fabric of ERC 5.5.0.29 and Emacs 29, not only in doc/misc/erc.texi but also in various doc strings of user options referencing it. Which leads me to believe that once ERC 5.6 is released, it'll be the upgrade method many users inevitably try. So I guess all of this amounts to my asking if some accommodation can be made server-side to special-case the massaging of ERC's package metadata into an agreeable format fully compatible with M-x list-packages RET on older Emacsen. Thanks, J.P. [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00419.html [2] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00635.html [3] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00734.html [4] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg00398.html [5] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01040.html [6] https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00511.html [7] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00911.html [8] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01396.html [9] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01435.html [a] https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00519.html [b] https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg00436.html [c] http://elpa.gnu.org/devel/doc/erc.html#Upgrading [d] https://lists.gnu.org/archive/html/emacs-erc/2023-04/msg00013.html