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:

>> Date: Sat, 6 May 2023 18:54:47 +0300
>> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> >> If some version of it is installed from ELPA (!) already, 'M-x
>> >> package-install' won't upgrade.
>> > 
>> > Then I don't understand why you decided to drop the similar change to
>> > package-upgrade.  At the time I thought package-install can be used as
>> > an alternative, but if it cannot, I think we should add to
>> > package-upgrade the same optional behavior of upgrading a built-in
>> > package as we have in package-install.
>> 
>> We now have a better solution on master: 'M-x package-upgrade' simply 
>> upgrades the built-ins, no questions asked.
>
> What we have on master is not relevant to what we discuss here, which
> is Emacs 29.
>
>> If we added the behavior similar to the addition in package-install 
>> (with prefix arguments and guarded by an option, possibly even a new 
>> optional argument), we'd have to carry over that awkward convention to 
>> Emacs 30 in some form. And as you recall, Joao wasn't happy with either 
>> solution anyway (of those that you liked enough).
>
> The question is: is it reasonable not to allow package-upgrade in
> Emacs 29 to upgrade a built-in package?  Not even as an option?

I think that would be fine.  The code looks fine, and considering the
commotion about this functionality and the effort that has been put into
preparing a minimal functional change, I think that it would be warranted
to allow for this change to be applies to emacs-29.

>> > What other methods currently exist to upgrade an already installed
>> > package (or a non-built-in package that is already installed)?  I know
>> > about one -- via lisp-packages (a.k.a. package menu); are there
>> > others?
>> 
>> Also:
>> M-x package-upgrade
>> M-x package-upgrade-all
>> 
>> > Will any of these methods upgrade a built-in package, at least as an
>> > optional behavior?
>> 
>> Not in Emacs 29.
>
> So I think we have a problem, and I think we need to solve it.
>
> Philip, Stefan: WDYT about this?
>
> What about installation from the list-packages menu: will it upgrade a
> built-in package if package-install-upgrade-built-in is non-nil?

Yes it will, which is why I find this discussion silly and have not been
following it in detail (also other non-emacs responsibilities have been
intervening).

>> > But if emptying ~/.emacs.d/elpa is not a frequent use case, why should
>> > we care about it so much?  It sounds like bug#62720 and the entire
>> > long dispute that followed were focused on this strange use pattern,
>> > instead of talking about more reasonable upgrade scenarios?
>> 
>> We focused on it because, apparently, using 'M-x package-install' worked 
>> in more cases in Emacs 28 than in Emacs 29. And some think it's 
>> important. And because 'package-upgrade' is not in Emacs 28 at all.
>
> If package-upgrade was not in Emacs 28, how did users upgrade
> installed packages in Emacs 28 and before?

They invoked M-x list-packages, waited for the upgrade to appear,
selected them with U and then executed the update with x.  This is what
used to work, and what will continue to work.  There was some mention
about problems with M-x list-packages, but I haven't heard of any
specific issues that could be addressed (I personally suspect it might
be an issue related to the tracking of the master or close-to-master
branches).

>> Personally, I think it's better to focus on fixing 'package-upgrade' 
>> (which I did). But I don't think it's constructive to hide that fix 
>> behind a pref.
>
> I don't see a zero-sum game here.  We could focus on both.  But I
> don't use package.el and never will, so if those who use it and
> maintain it think otherwise, I won't insist.  Although I find this
> stance very strange indeed, to say the least.

(This explains some of the confusion, I was under the assumption that
some of your questions were from a position of Socratic ignorance,
but if you don't use it at all, then some of the past confusion makes
more sense to me.)