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

From: Philip Kaludercic <[email-masked]>
Date: Sat, 15 Apr 2023 17:14:41 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Philip Kaludercic <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Sat, 15 Apr 2023 13:21:53 +0000
>> 
>> >> - User option to enable upgrading built-in packages
>> >> - Prefix argument to enable upgrading built-in packages
>> >> - Always upgrade built-in packages
>> >
>> > The first two on emacs-29, the last one on master (if enough people
>> > think it's a good idea; me, I think we should wait for a while before
>> > deciding).
>> 
>> OK, so let us use this change:
>> 
>> (I intentionally picked this one without the user option since that
>> will probably become unnecessary with Emacs 30+).
>
> The user option allows those users who always want package-install to
> upgrade core package to have what they want, easily.  So I think we
> should keep it.  On master, the option could be t by default, or
> become unnecessary if that's what happens (but I wouldn't bet on
> that).

My argument against a user option is just that the whole deal is
something that will in practice at most affect two packages (if we
change the behaviour in Emacs 29).  Is it really worth adding a general
option for this very specific situation?

>> I believe there was an issue with the name
>> `package--upgradable-built-in-p' and the docstring?
>
> Yes.  The doc string has a typo:
>
>   "Return non-nil if PACKAGE if the built-in version is used."
>
> See those two "if"s?  And even if I replace the second "if" with "is",
> the sentence doesn't make sense.

Right, how does

  "Return non-nil if the built-in version of PACKAGE is used."

sound?

> As for the name, I think we can leave it at that.

Ok.

> Thanks.

-- 
Philip Kaludercic