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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 14 Apr 2023 20:03:31 +0100
> Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, 62720@debbugs.gnu.org, 
> 	larsi@gnus.org, philipk@posteo.net
> 
> > > OK, but who does this and why, in your opinion?  And who has
> > > `(package-install seq)` in their config and why?  And won't they get
> > > the same updated 'seq' "accidentally" if they install anything else
> > > that depends on newer seq, which is likely a lot of non-core
> > > packages and likely to grow?
> >
> > I don't know.  But we did have core packages that were also on ELPA
> > before Emacs 29, and people did get along with that.  So much so that
> > I don't recall any complaints about this, definitely not complaints
> > that claimed package.el is as badly broken as you seem to represent.
> 
> I think it's simply and clearly because there weren't any non-core
> packages that migrated to core before.  Were there?  Certainly
> none with as fast a release cycle like Eglot's.

You are missing the point.  My point is that users of all those other
core packages are used to the current situation, where package-install
doesn't update the built-ins.  They have workflows based on that.
Those are the workflows that I don't want to risk breaking.

Once the discussion with Philip runs to its completion, we _will_ have
in Emacs 29.1 a way of upgrading built-ins, only not by default, but
by an explicit user request.  Maybe this is not ideal, but we don't
have time to find out what is ideal for all those involved, and this
partial solution allows to get the job done without risking to break
anyone's workflow.  So this is a good compromise, given the time and
the constraints, at least from my POV.

> > I said "in effect calling for breaking them".  You need to realize
> > this might be the outcome of what you are requesting, even if your
> > intentions are benign.
> 
> I _am_ realizing that, and even if I think the risks are minuscule,
> I'm providing solutions that mitigate them.  And -- responsibly, I
> think -- pointing to the fact that the risk surface is much larger
> than you may think it is.

I respectfully disagree with your assessment of the risks.  And
eventually, it is my responsibility to do this job, so my assessment
of that is what counts more.  I've heard all of your arguments (and
also those of others), and considered all of them, and I still don't
think the risk is high enough to justify the potentially-breaking
changes that you propose, not on the release branch, not this late
into the release cycle.

> > > I even proposed making a simple whitelist of packages that have
> > > migrated from outside core to core.  And I've proposed confirmation
> > > prompts for the interactive calls.  And others have proposed
> > > blacklists.  These things are trivial to implement in Elisp.
> >
> > They are not trivial enough to be considered for emacs-29.  On master,
> > sure, feel free to install such changes, if the others agree.
> 
> Are you saying it's OK to propose this blacklist/whitelist idea?

For the release branch?  No.  For master?  Yes.

> I will work and prepare that patch if you promise to at least
> look at the code, follow the logic with me and consider the
> patch for backporting if it's as safe as relying on a simple
> `(if (memq package package-safely-upgradeable-builtins) ...)`

Backporting can be considered for Emacs 29.2, not before that.
Hopefully, by that time we will also have more data points regarding
the various uses of this, in particular with Eglot, so that our
decisions will be more informed.