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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 19 Apr 2023 20:15:20 +0100
> Cc: arne_bab@web.de, jporterbugs@gmail.com, dmitry@gutov.dev, 
> 	emacs-devel@gnu.org
> 
> On Wed, Apr 19, 2023 at 7:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It has similar problems: it will automatically update packages
> > mentioned in package--safely-upgradeable-builtins, which might not be
> > what users want for built-in packages.
> 
> It is what they want, by definition, this is why I named it
> "safely-upgradeable-builtins".  These are the users:
> 
>   Specifically, users of Emacs 28 and older, who had Eglot installed,
>   and expect Eglot to be automatically updated upon Emacs startup
>   whenever a new Eglot version is available, will now have their
>   expectations broken after they upgrade to Emacs 29, because Eglot is
>   now a built-in package, and package.el won't by default upgrade a
>   built-in package.
> 
> Recognize this writing? It is yours!

Yes.  Of course, you conveniently omitted the next paragraph I wrote,
which described a different group of users, whose expectations would
be broken by the changes you proposed.  That was also "my writing".

> > You assume that everyone will
> > want Eglot and use-package automatically updated, but this assumption
> > has no real basis.
> 
> First, of course it has real statistical basis! Didn't I send you
> links to tens and tens of issues were users reported their configurations
> and one can actually see what users are doing to install Eglot?

Since when "tens" and "everyone" are the same thing?

> Secondly, it has the theoretical basis of what you wrote yourself
> barely 1 hour ago!  It shows you understand the problem that is
> new in Emacs 29.

Of course, I understand the problem.  But understanding the problem
doesn't mean agreement with the solutions you propose, or any other
solution, for that matter.  An acceptable solution should solve the
problem without causing other problems, and in this case it also must
solve the problem in a safe enough manner to be eligible for Emacs
29.1.

> Using your language, we want to not "break those user's expectations".
> if we can.  And we can, if you want to.  You want to, right? You want to
> break as few user's expectations as possible, ideally 0.
> 
> And the code does exactly that! It avoids bothering that set of
> users while also avoiding bothering the other set of users that
> you mentioned.
> 
> And, for good measure, the set of users who had Eglot installed
> and expect Eglot NOT to be updated when package-install is found
> is the empty set.  Surely this is evident.
> 
> So there's no "dilemma".  There is rather some kind of spectacular
> misunderstanding here.  There has to be, because I'm drawing these
> conclusions from nothing more than elementary facts from set theory

It is clear that you like the solution you proposed, and see no
problems with it.  But I disagree, and at this point I have explained
my disagreement enough times.  If you still think I'm wrong, please,
just let's leave this disagreement as it is.  Repeating the same
arguments over and over again just wastes bandwidth and our time.

> > Plus, it adds to the maintenance burden of maintaining this
> > (internal? not a defcustom??) variable for good.
> 
> We can make it a defcustom if you want.  That's exactly
> Jim's idea.  I was just trying to make the simplest thing
> possible.  This is just for Emacs 29.  You asked for little
> code and this is much less code (less cyclomatic complexity,
> etc) than what you eventually accepted.  So I was just trying to
> cover that front too.

I said I'm okay with a defcustom if its default value is nil.

Of course, we already added a defcustom to allow built-in packages to
be updated, so I'm not sure another one is needed.