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

[Dmitry Gutov]

On 19/04/2023 21:32, Eli Zaretskii wrote:
> > Date: Wed, 19 Apr 2023 21:14:06 +0300
> > Cc: arne_bab@web.de, jporterbugs@gmail.com, emacs-devel@gnu.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > On 19/04/2023 21:07, Eli Zaretskii 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.
> >
> > IMO that kind of choice could be deferred to the maintainer of each
> > individual package.
>
> No, it cannot, and this and the sibling discussions show why: the
> package maintainers are biased in favor of their packages.  That
> (completely understandable and expected) bias prevents them from
> seeing the overall picture objectively.

I don't know, I never really minded that project.el and xref aren't 
upgraded too often.

Though to be honest I would still expect that, when the user types 'M-x 
package-install', they'd be able to upgrade project or xref to the 
latest version. Simply because that looks like an unambiguous request 
for this exact outcome.

> > Or make it a defcustom if you're really worried.
>
> That doesn't change the picture, unless the default for the defcustom
> will be nil.  Which I expect João to object to, because he wants Eglot
> to be updated by default and automatically.

Only when their init script contains

  (package-install 'eglot)

or

  (use-package 'eglot :force t)

right?

> Whereas I think the
> compromise, whereby the user should say just once that he/she wants
> Eglot to be automatically updated, is a good compromise given the
> constraints in this case.  Not ideal, but a good-enough compromise.

Might be. In saying the above I'm thinking about a different issue: user 
options should be logical (as much as we possibly manage). When they 
are, they are easier to find and enable.

So if we absolutely can't resolve the problem using the solution 
previously recommended by Philip, Joao and I, we should at least choose 
the most logical among approaches containing a new user option.