GNU bug report logs - #62720
29.0.60; Not easy at all to upgrade :core packages like Eglot

Previous Next

Full log

Message #380 received at 62720 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: larsi <at> gnus.org, 62720 <at> debbugs.gnu.org, rpluim <at> gmail.com, philipk <at> posteo.net,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#62720: 29.0.60; Not easy at all to upgrade :core packages
 like Eglot
Date: Fri, 14 Apr 2023 21:49:14 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 14 Apr 2023 19:32:40 +0100
> Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, 62720 <at> debbugs.gnu.org, 
> 	larsi <at> gnus.org, philipk <at> posteo.net
> 
> On Fri, Apr 14, 2023 at 6:49 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > when you say "compatibility", you seem to have only one its aspect in
> > mind: that of Eglot.  But that is not the only aspect of the previous
> > behavior, and I, at least, must consider those other aspects as well.
> 
> You seem to be worried about "everyone else" typing, say, M-x package-install
> RET seq RET and getting an updated 'seq' as a result.

That, too.  But also everything else.  Any incompatible change of
behavior can potentially break someone's workflow.

> OK, but who does this and why, in your opinion?  And who has
> `(package-install seq)` in their config and why?  And won't they get
> the same updated 'seq' "accidentally" if they install anything else
> that depends on newer seq, which is likely a lot of non-core
> packages and likely to grow?

I don't know.  But we did have core packages that were also on ELPA
before Emacs 29, and people did get along with that.  So much so that
I don't recall any complaints about this, definitely not complaints
that claimed package.el is as badly broken as you seem to represent.

> But even if these people and use cases did exist, you're still
> plainly misrepresenting my position by writing that I'm "calling
> for breaking" them.

I said "in effect calling for breaking them".  You need to realize
this might be the outcome of what you are requesting, even if your
intentions are benign.

> I even proposed making a simple whitelist of packages that have
> migrated from outside core to core.  And I've proposed confirmation
> prompts for the interactive calls.  And others have proposed
> blacklists.  These things are trivial to implement in Elisp.

They are not trivial enough to be considered for emacs-29.  On master,
sure, feel free to install such changes, if the others agree.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.