[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: |
Sat, 22 Apr 2023 15:00:29 +0300 |
> Date: Sat, 22 Apr 2023 14:24:47 +0300
> Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org,
> joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 22/04/2023 14:11, Eli Zaretskii wrote:
> >> Date: Sat, 22 Apr 2023 13:30:41 +0300
> >> Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org,
> >> joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >>> Thanks, but this is not what was being discussed, AFAIU. What I said
> >>> I'd agree to is to have package-update accept a prefix argument and
> >>> heed package-install-upgrade-built-in (perhaps renamed),
> >>
> >> I think I explained in the previous email why reusing
> >> package-install-upgrade-built-in doesn't seem like a good idea.
> >
> > And I thought I've explained why I didn't see a need for another
> > option.
>
> I also don't see the point of using an option here.
We must not change past behavior unconditionally and by default, not
this close to the release.
> Also think forward to Emacs 30: I think the most reasonable choice would
> be to have package-update upgrade builtins by default, whereas
> package-update-all and package-menu-mark-for-upgrades probably still
> need to be preffed off (not sure, but we won't be able to make the
> choice until later, I think).
I don't see why package-update and package-update-all should behave
differently wrt core packages. If the user expresses his/her will to
update core packages, then package-update-all should do this for all
of them.
> But if to make package-update behave properly we need to flip the
> default of the said option, it will flip the behavior of
> package-update-all and package-menu-mark-for-upgrades as well.
Which is how it should be, IMO.
> >>> and only then
> >>> update built-in packages.
> >>
> >> I asked what plausible scenario you think might be broken by having
> >> package-update upgrade builtin package by default.
> >
> > That's obvious: this is how package-update behaved until now.
>
> That's not an answer to the question.
It is for me (and I'm quite surprised that it is not for you).
> >>> I also don't think I like the significant changes in package-update,
> >>> nor understand why they are needed.
> >>
> >> Like I said: the changes are to avoid relying on package-install being
> >> able to install a package that's already installed. Which currently
> >> works only for builtins and when only a user option is set. It's a mess.
> >>
> >> And to "avoid interdependency".
> >
> > Why does this have to be in Emacs 29? It's a cleanup, right?
>
> Not a cleanup, no. If I just keep the previous version of the code, I
> get "package xxx is already installed". Because when upgrading a builtin
> package, the "current" version is not deleted.
>
> So we need to compute the exact version to install (then package-install
> does not say "it's already installed" because the installed version is
> different). The use of package-install-from-archive might have been a
> mistake, though, (in case dependencies need to be updated too) I'm
> looking into that now.
With prefix argument, or when package-update-built-in is non-nil, the
behavior of package-install is different. So just use this, instead
of changing the code of package-update.
> Alternatively, we could add an optional argument to package-install
> which would mean "install the latest version anyway".
There is already such an option, added as part of fixing this bug.
> >> Just to be clear, we are talking about the 4 lines at the end, right?
> >
> > Yes, and also the (somewhat mysterious) additions of tests for
> > pkg-desc.
>
> pkg-desc is nil for builtin packages in this case (they are not in
> package-alist, so (assq package package-alist) returns nil).
This should either be commented, or a variable with a telltale name
added to reflect this subtlety.
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, (continued)
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/21
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot,
Eli Zaretskii <=
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/22
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/23
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/24