bug#68660: 29.2; ELPA: Wrong type argument w. multiple maintainers in package-menu-mode

["J.P." <jp@neverwas.me>]

Hi Stefan,

Stefan Monnier <monnier@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@gnu.org")
>>                ("Mats Lidell" . "matsl@gnu.org"))
>>
>> and
>>
>>   ;; /packages/archive-contents
>>   (:maintainer "Bob Weiner <rsw@gnu.org>, 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 ‘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