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

[Dmitry Gutov <dmitry@gutov.dev>]

On 22/04/2023 03:57, João Távora wrote:

> Then there are the things I can't change, like users trying out
> a new init.el file, a very common operation -- be it for bug
> reproduction or just to try something out.  Also note that
> package-delete + package-install interactively is a  pretty good way
> to update packages in Emacs 28: no need to nuke the home directory.

It's as good a workaround for ignorance as any, but if we think it's 
okay for a user to do that (a relatively large manual operation), 
perhaps we can guide them to do a 'package-install' from list-packages 
instead.

But the difference from Emacs 28 is indeed unfortunate, no argument there.

Or if the new option stays around, I guess you could be recommending 
they customize it first?

> If you "dont buy this", that's OK :-) I'm not trying to sell it to you
> specifically.  I don't think we'll have torches and pitchforks either,
> but we're not really talking about "spacebar overheating" here.
> 
> Note that I also don't really buy, personally, the "furtive update of
> :core packages" argument either.  My reasoning is that that cat has
> been out of the bag for a long long, just because of dependencies which
> are absolutely liberally by package.el and the fact tha I've never seen
> a bug reported about this.

I don't have a strong opinion one way or the other, but this part seems 
to be worth treating conservatively, I think. This close to release, etc.

We might as well switch to the "update all the cores!" model later, but 
hopefully by that time we have a good CI setup that tests the 
compatibility of all core packages with all Emacs versions they are 
supposed to support.

> I buy even less that people using M-x package-update in Emacs 29
> don't want to update :core packages just because it doesn't do
> that right now.  For me, it's obvious people weren't using to
> update :core packages because that command lived in master
> for the large part of its short life and in master :core packages
> don't need any updating, by definition. But of course fact that I
> don't buy it  shouldn't mean that it should be disregarded (and
> noone is advocating for that).

This one I'm trying to fix, currently.

> The last two patches I provided aim to aid Eglot users (lightly,
> as you've discovered, since the use-package use case is not well
> covered in the first one, and there's still the error behaviour
> to ponde).  But, more importantly they are designed so that no
> cats that weren't previously out of the bag make it outside
> the bag

Do you prefer that package-install-upgrade-built-in (together with the 
behavior of package-install it enables) stays around?

One possible alternative I mentioned, is package-install could grow 
another programmatic parameter which would mean "install the very latest 
version". The users will then need to evaluate (package-install 'eglot 
nil t) for that to happen. Also a breaking change in instructions, 
though, since in Emacs 28 this will error.

Another gotcha with the latter, is that if some version from ELPA is 
already installed, they will get two versions installed as a result.