Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Sun, 07 May 2023 19:44:01 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: dmitry@gutov.dev,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> >> Date: Sun, 07 May 2023 19:24:26 +0000
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> but on my system, it immediately suggests upgrading 24 packages, which
>> >> >> is a lot.
>> >> >
>> >> > Can you show the list of those 24 packages?
>> >> 
>> >> I am on a different system now, so the prompt differs slightly and have
>> >> other updates, but this is what it looks like:
>> >> 
>> >> Packages to install: 23 (xref-1.6.3
>> >> verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4
>> >> svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8
>> >> org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6
>> >> jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5
>> >> eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3 bind-key-2.4.1).
>> >> Packages to upgrade: 2 (editorconfig-0.9.1 inspector-0.29).
>> >> Proceed? (y or n)
>> >
>> > I see nothing unexpected in this list.  And since the feature is
>> > opt-in, what are the dangers of having it?
>> 
>> There is no danger, it might just be overwhelming?  I was a bit
>> surprised at first.  But if you think it is fine, then I have no
>> objections.
>
> One more question: the patch you proposed affects both "U" and "/ u",
> right?

Yes it does, since both of these functions use
`package-menu--find-upgrades'.  In the future, we should probably
centralise the upgrade logic in a single function, like
`package--upgradeable-packages'.

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 7 May 2023 23:36:24 +0300
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 07/05/2023 22:32, Eli Zaretskii wrote:
>> > Packages to install: 23 (xref-1.6.3
>> > verilog-mode-2022.12.18.181110314 use-package-2.4.5 tramp-2.6.0.4
>> > svg-1.1 soap-client-3.2.1 so-long-1.1.2 python-0.28 project-0.9.8
>> > org-9.6.5 ntlm-2.1.0 nadvice-0.4 map-3.3.1 let-alist-1.0.6
>> > jsonrpc-1.0.17 flymake-1.3.4 external-completion-0.1 erc-5.5
>> > eldoc-1.14.0 eglot-1.15 cl-lib-0.7.1 cl-generic-0.3
>> > bind-key-2.4.1).  Packages to upgrade: 2 (editorconfig-0.9.1
>> > inspector-0.29).  Proceed? (y or n)
>> 
>> At least nadvice, cl-lib and cl-generic seem to be the odd ones (the 
>> built-in versions are higher, and the ELPA packages are supposed to be 
>> used as shims or backward compatibility wrappers). That looks like a bug.

I think you are right, I can extend my previous patch by a version check.

> Yes, I think it's an unrelated bug.  We had already reports about
> strange status values, and there's a new bug#63064 today about similar
> problems.  We should try to fix this for Emacs 29, I think.
>
>> Regarding potential downsides in general:
>> 
>> - We simply increase the odds of breakage when a built-in package is 
>> upgraded because it will reach more people, across different Emacs 
>> versions. There is good and bad in that (features will reach them faster 
>> too), but it's something to consider.
>> 
>> - I very rarely use Tramp or Org. I don't use ERC or bind-key. Or 
>> so-long, python, ntlm, use-package, verilog-mode. Unlike other installed 
>> packages (which I have hand-picked), these packages are here just by the 
>> virtue of being included in Emacs, but flipping the pref will also cause 
>> them to be upgraded (downloaded, take time unarchiving, take up space) 
>> every time there is a new version out. It's nothing dangerous 
>> (probably), but seems unfortunate anyway.
>
> AFAIU, the "U" command is not for everyone.  There are alternatives
> which allow selective upgrades, and users who don't want "surprises",
> or want the upgrade to take as little time and disk space as possible,
> should use those alternatives instead of "U".  I'll try to make that
> clear in the documentation.

I think that U is pretty standard, but yes, those who cannot use it are
free to select the packages they wish to upgrade manually (that being
said, Emacs was never known for being popular among people who are
struggling for every kilobyte of disk space).