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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: joaotavora@gmail.com,  monnier@iro.umontreal.ca,  62720@debbugs.gnu.org
>> Date: Sat, 15 Apr 2023 17:14:41 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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 think we should count users of those packages, not just the packages
> themselves.  Yes, I think it's worth it, because we don't know how
> many of the users will want the built-in packages to be included in an
> update.

OK, see below.

>> >   "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?
>
> I think we should explain what does "the built-in version of PACKAGE
> is used" mean, in the context in which this predicate is used.  Maybe
> say something like
>
>     Return non-nil if the built-in version of PACKAGE is used.
>   If the built-in version of PACKAGE is used and PACKAGE is
>   also available for installation from an archive, it is an
>   indication that PACKAGE was never upgraded to any newer
>   version from the archive.

Sounds good to me.

0001-Allow-upgrading-built-in-packages-with-package-insta.patch
Description: Text Data

-- 
Philip Kaludercic