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

Previous Next

Full log

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

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

On Fri, Apr 14, 2023 at 4:52 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > Maybe you can answer this: if a user is setting up Emacs 28 in company
> > laptop machines regularly and does M-x package-install RET eglot RET there,
> > or has a script with (package-install 'eglot), should or shouldn't this
> > user, in your opinion, be allowed to do exactly the same, with the same
> > predictable results (in this case getting the latest Eglot), when she starts
> > doing the same in Emacs 29, which now contains Eglot as a built-in?
>
> Good point.  I think the answer is that we should distinguish "install"
> from "upgrade" (and offer a way to do both, of course).
>
> And I think we do want to break backward compatibility here (arguably we
> even can't not break compatibility), because the Emacs<29 semantics of
> `package-install` is "broken", since it does "install&upgrade" for
> non-builtin packages but not for builtin packages: either we keep that
> semantics and compatibility is broken when packages move to/from
> builtin, or we change that semantics and compatibility is broken by the
> change in semantics :-)

I would think it's too late in the game to break compatibility.
Naming aside package-install has certain behaviour that for a certain
set of inputs used to produce predictable things.
Now, for the same inputs it does nothing on Emacs 29.

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.  Presumably, the packaging
system where it takes less than a day to fix release a bug fix and
deliver this to the archives, should be the protection.

Previous Next

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