emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stability of core packages (was: Not easy at all to upgrade :core pa


From: Eli Zaretskii
Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)
Date: Wed, 19 Apr 2023 21:07:47 +0300

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 19 Apr 2023 18:21:23 +0100
> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, jporterbugs@gmail.com, 
> dmitry@gutov.dev, 
>       emacs-devel@gnu.org
> 
> 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.

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.  You assume that everyone will
want Eglot and use-package automatically updated, but this assumption
has no real basis.  I object in general to any feature that
unexpectedly installs some software without the explicit user's
say-so.

Plus, it adds to the maintenance burden of maintaining this
(internal? not a defcustom??) variable for good.

Those issues were enough for me to reject the proposal.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]