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

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

On Fri, Apr 14, 2023 at 7:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Fri, 14 Apr 2023 19:32:40 +0100
> > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, 62720@debbugs.gnu.org,
> >       larsi@gnus.org, philipk@posteo.net
> >
> > On Fri, Apr 14, 2023 at 6:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > when you say "compatibility", you seem to have only one its aspect in
> > > mind: that of Eglot.  But that is not the only aspect of the previous
> > > behavior, and I, at least, must consider those other aspects as well.
> >
> > You seem to be worried about "everyone else" typing, say, M-x package-install
> > RET seq RET and getting an updated 'seq' as a result.
>
> That, too.  But also everything else.  Any incompatible change of
> behavior can potentially break someone's workflow.

Of course.  But what is this "everything else" pandora's box that
the solution I'm proposing unleashes?  I just don't see the
connection.

> > 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.

> > But even if these people and use cases did exist, you're still
> > plainly misrepresenting my position by writing that I'm "calling
> > for breaking" them.
>
> 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 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?
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) ...)`

If you don't want to do that, I'm not going to propose it, because
that in effect means I'm adding code that will only have any effect
in the Emacs 30 release, and the Emacs 29 will be a very odd
release in this aspect for several years to come.  And this is an even
worse outcome.

João