emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.
Date: Sat, 06 May 2023 19:40:25 +0300

> 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?

> > 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?

> > 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?

> 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.



reply via email to

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