GNU bug report logs - #62720
29.0.60; Not easy at all to upgrade :core packages like Eglot

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: larsi <at> gnus.org, 62720 <at> debbugs.gnu.org, philipk <at> posteo.net, monnier <at> iro.umontreal.ca
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 12 Apr 2023 08:49:14 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Tue, 11 Apr 2023 21:08:32 +0100
> Cc: "Philip K." <philipk <at> posteo.net>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 62720 <at> debbugs.gnu.org, 
> 	Lars Ingebrigtsen <larsi <at> gnus.org>
> 
>  > If this change can't go into emacs-29, I think it's better to add
>  > an M-x eglot-update to eglot.el.
> 
>  That's the worst of all worlds.
> 
> Why? It's the safest option. Absolutely no package.el regression possible, and doesn't solve a problem
> where you don't think I've exists.

From your POV of the Eglot maintainer, it might make sense.  But from
my POV, it doesn't: the problem here is general, and a solution is at
hand that will give you what you want and also support all the other
core packages.

>  What is the problem with the two possible solutions I suggested?
> 
> They are incongruent and not very user friendly IMO.

The one which proposed a new command is a natural generalization of
your eglot-update proposal, so I think it is as user-friendly as it
gets.  As for congruency, Stefan just expressed his intuition about
that, and I tend to agree with him: upgrades of core packages should
indeed be handled by separate command(s) with somewhat different rules
and perhaps also a different UI.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.