GNU bug report logs -
#62720
29.0.60; Not easy at all to upgrade :core packages like Eglot
Previous Next
Reported by: João Távora <joaotavora <at> gmail.com>
Date: Fri, 7 Apr 2023 22:11:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #179 received at 62720 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: João Távora <joaotavora <at> gmail.com>,
>> monnier <at> iro.umontreal.ca,
>> 62720 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Wed, 12 Apr 2023 12:00:09 +0000
>>
>> > Yes, if Philip and Stefan don't object. But, since there will be a
>> > command for updating core packages, doesn't this go against your
>> > desire not to change the UX?
>>
>> After thinking about this for a bit, I think that the right approach is
>> to use package-install instead of writing a separate command. After
>> all, this will make the behaviour of package-install consistent with
>> that of the package menu.
>
> Is this for master or for the release branch?
Personally I am indifferent, it should be compatible with both
> And I thought we all agreed built-in packages need special treatment
> anyway, didn't we? Then why having a separate command is not a
> natural next step?
I don't necessarily agree that "special treatment" requires a separate
command. I think it is wrong the assume that an built-in package should
automatically be updated to a ELPA package whenever possible.
It might be that I misunderstood something about your long-term plan
where package-install wouldn't suffice. I'll go re-read the thread to
check.
>> It might work but it should be tested somewhat thoroughly before the
>> patch is applied. In the meantime, I just finished a similar approach
>> that does not modify `package-installed-p', but just adds another
>> utility function:
>
> A new utility function is fine by me, even if this is e branch. But I
> don't quite understand how this is supposed to work in package-install
> to allow updating built-in packages, and do that in a way that will
> not touch the existing code for non-built-in packages in significant
> ways (assuming you propose this from the release branch). Can you
> elaborate on that?
The only reason we couldn't install built-in packages is that when
planning to install packages `package-compute-transaction' believes that
if a built-in package is provided, then everything is fine and we don't
need to proceed with installing any packages. All I propose is to lift
this assumption, then this works fine.
One point that might be deliberated is that this means all built-in
dependencies are also installed, even if these are not strictly
necessary. It shouldn't matter that much, since most users would
upgrade them eventually, but worth mentioning I guess?
>> +(defun package-core-p (package)
>> + "Return non-nil the built-in version of PACKAGE is loaded."
>
> Didn't you say the "core" terminology was confusing people?
TBH I am not really satisfied with the name (so any other suggestion is
just as fine for me), and as Joao said it would be better to make the
predicate as internal so that users are not expected to deal with it.
>> + (let ((package (if (package-desc-p package)
>> + (package-desc-name package)
>> + package)))
>> + (and (assq package (package--alist))
>> + (package-built-in-p package))))
>
> It sounds like this doesn't check whether a package is "core", it
> checks whether it's built-in and can be updated? So maybe the name
> should be changed to reflect that? And the doc string as well (what
> it means by "is loaded")?
Right the "loaded" doesn't make sense. How about this:
[0001-Allow-upgrading-built-in-packages.patch (text/x-diff, attachment)]
This bug report was last modified 2 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.