bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: 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@gmail.com>
> Date: Fri, 14 Apr 2023 19:32:40 +0100
> Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, 62720@debbugs.gnu.org, 
>       larsi@gnus.org, philipk@posteo.net
> 
> On Fri, Apr 14, 2023 at 6:49 PM Eli Zaretskii <eliz@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.





reply via email to

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