Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

["João Távora" <joaotavora@gmail.com>]

On Wed, Apr 19, 2023 at 6:02 PM Eli Zaretskii <eliz@gnu.org> wrote:

> OTOH, the proposal to change package.el so it automatically updates
> built-in packages as well would break the workflows of people who
> don't expect built-in packages to be updated: they would suddenly see
> packages like ElDoc or Xref or Project (and others) being updated
> automatically at startup instead of staying at the version shipped
> with Emacs.

OK. In my initial evaluation I disagreed that this was a problem,
because that has always happened in Emacs 28.

But I acknowledge that if some user has

  (package-install always-has-been-a-core-package)

in her Emacs 26/27/28 config, then some behaviour would have been
changed with some of my previous solutions.  I give you that, it
doesn't need contesting.

And that is why I later I gave a solution that _doesn't_,
I repeat, _doesn't_ let that happen.  That solution is in

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#467

It's a minimal patch, much smaller than the one that did make
it in.  I've linked to it many times now, but it has always
been ignored by all except Philip and Dmitry, who said it was a
"fine" solution and +1, respectively.

It will _not_ update Xref and ElDoc _unless_ the user specifically
asked for Eglot to be installed.  Which is, of course, exactly what
happened already in Emacs 28. For example, if the user has

  (package-install 'project)

It _won't_ be updated. And neither will its dependency Xref. Again, just like
in Emacs 28.

Why are we ignoring my patch? What's really wrong with it? In
technical terms, if possible.

> So there's a dilemma here: which of the two groups of users to break?

There's no dilemma.  There's no need for the heavy-handed solution
you chose that breaks one of the groups of users.  Presumably it was
the one you judged least numerous/valuable.  I don't even want to
dispute that judgement, because there's no need!  We can have
perfectly backward-compatible behavior, so if we value it, let's
have it.

João