Package: emacs;
Reported by: "J.P." <jp <at> neverwas.me>
Date: Mon, 22 Jan 2024 14:58:02 UTC
Severity: normal
Found in versions 29.4, 29.2
View this message in rfc822 format
From: "J.P." <jp <at> neverwas.me> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: emacs-erc <at> gnu.org, 68660 <at> debbugs.gnu.org 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
Hi Stefan,
Stefan Monnier <monnier <at> iro.umontreal.ca> 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 <at> gnu.org")
>> ("Mats Lidell" . "matsl <at> gnu.org"))
>>
>> and
>>
>> ;; /packages/archive-contents
>> (:maintainer "Bob Weiner <rsw <at> gnu.org>, Mats Lidell"
>> . "matsl <at> 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 ‘M-x list-packages <RET>’. In the ‘*Packages*’
(‘package-menu-mode’) buffer, click the ‘erc’ 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 ‘help-mode’
buffer, confirm the version and click ‘Install’. [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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.