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

Previous Next

Package: emacs;

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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: larsi <at> gnus.org, 62720 <at> debbugs.gnu.org, joaotavora <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 12 Apr 2023 15:30:20 +0300
> 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?

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?

> 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?

> +(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?

> +  (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")?

Thanks.




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.