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

Previous Next

Full log

View this message in rfc822 format

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

On Fri, Apr 14, 2023 at 6:49 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > I think it should do the same thing, not only because it's
> > nicer for the unsuspecting user, but also because trying to
> > protect this user from "unintentional" upgrade of certain "unstable"
> > packages, as it seems to be the idea here, is a losing game
> > anyway, just because dependencies.
>
> "The same thing" for Eglot means "not the same thing" for other core
> packages.  So you are in effect calling for breaking everyone else to
> cater only to Eglot.  That is not going to happen, for more than one
> reason.

> 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.  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 just
can't see these "other aspects", i.e. who or whose use cases you wish to
protect with multiple user knobs to get a razor thin level of protection.

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

João

Previous Next

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