GNU bug report logs - #76978
31.0.50; Archive information not displayed for installed packages in *Packages* buffer

Previous Next

To reply to this bug, email your comments to 76978 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Archive information not displayed for installed packages in
 *Packages* buffer
Date: Wed, 12 Mar 2025 09:23:32 -0400

[Message part 1 (text/plain, inline)]

When a package is installed or is a dependency, the "Archive" column in
the *Packages* buffer does not display the archive information.  This
happens because the function `describe-package-1` in `package.el` skips
the Archive section for installed packages due to the following
conditional check:

(unless (and pkg-dir (not archive)) ; Installed pkgs don't have archive.
  (package--print-help-section "Archive"
    (or archive "n/a")))

The expected behavior is that the "Archive" column should display the
archive name (e.g., "gnu", "nongnu", "other unofficial archive") for
packages in the installed or dependency status.  This would be helpful
because:

1. Traceability: It would allow users to easily identify the source archive
   of a package, which is useful for debugging, auditing, and understanding
   the package's origin.

2. Security: It would provide users with additional context about the
   package's source, helping them make informed decisions about the code
   they use.

3. Consistency: Archive information is part of the package metadata, and
   displaying it consistently would improve the user experience by making
   this information readily available.

Currently, the archive information is not displayed for installed or
dependency packages, which makes it harder to track the source of these
packages.  This behavior is implemented in the `describe-package-1`
function in `package.el`, starting around line 2890.  A review of this
behavior would be appreciated to ensure users have access to this helpful
metadata.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2025-02-26 built on fedora
Repository revision: 8c165834913bb0dca214acc4b82ba1d9d4ac0a82
Repository branch: master
System Description: Fedora Linux 41 (Workstation Edition)

Configured using:
 'configure --with-imagemagick --with-pgtk --with-tree-sitter
 --with-mailutils --with-sound=yes --with-pdumper=yes
 --with-dumping=pdumper --with-file-notification=yes'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt mm-archive message sendmail
yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
time-date mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode
mail-utils mule-util cus-edit pp cus-start cus-load wid-edit gnutls
network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny compile
text-property-search comint ansi-osc ansi-color ring comp-run
comp-common rx epg rfc6068 epg-config display-line-numbers finder-inf
package browse-url xdg url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 309513 44932) (symbols 48 11458 0) (strings 32 55510 3235)
 (string-bytes 1 1431141) (vectors 16 20605)
 (vector-slots 8 250601 12665) (floats 8 225 47)
 (intervals 56 25047 0) (buffers 992 12))

-- 
David

[Message part 2 (text/html, inline)]

Message #8 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org
Subject: Re: bug#76978: 31.0.50; Archive information not displayed for
 installed packages in *Packages* buffer
Date: Sun, 16 Mar 2025 09:42:57 +0000

(Tip: When creating a bug report that you assume specific people are
interested in, adding a X-Debuggs-CC header will send the people a
message and add them directly to the CCs.)

david <davidimagid <at> gmail.com> writes:

> When a package is installed or is a dependency, the "Archive" column in
> the *Packages* buffer does not display the archive information.  This
> happens because the function `describe-package-1` in `package.el` skips
> the Archive section for installed packages due to the following
> conditional check:
>
> (unless (and pkg-dir (not archive)) ; Installed pkgs don't have archive.
>   (package--print-help-section "Archive"
>     (or archive "n/a")))
>
> The expected behavior is that the "Archive" column should display the
> archive name (e.g., "gnu", "nongnu", "other unofficial archive") for
> packages in the installed or dependency status.  This would be helpful
> because:
>
> 1. Traceability: It would allow users to easily identify the source archive
>    of a package, which is useful for debugging, auditing, and understanding
>    the package's origin.
>
> 2. Security: It would provide users with additional context about the
>    package's source, helping them make informed decisions about the code
>    they use.
>
> 3. Consistency: Archive information is part of the package metadata, and
>    displaying it consistently would improve the user experience by making
>    this information readily available.
>
> Currently, the archive information is not displayed for installed or
> dependency packages, which makes it harder to track the source of these
> packages.  This behavior is implemented in the `describe-package-1`
> function in `package.el`, starting around line 2890.  A review of this
> behavior would be appreciated to ensure users have access to this helpful
> metadata.

As mentioned in another thread, my suggestion to solve this issue is to
track the installation-source in the `package-desc-extras' plist.  This
seems to be the least invasive approach I can think of, which should be
simple to implement.

The question then is how and where to display the installation-source?.

>
> In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.43, cairo version 1.18.2) of 2025-02-26 built on fedora
> Repository revision: 8c165834913bb0dca214acc4b82ba1d9d4ac0a82
> Repository branch: master
> System Description: Fedora Linux 41 (Workstation Edition)
>
> Configured using:
>  'configure --with-imagemagick --with-pgtk --with-tree-sitter
>  --with-mailutils --with-sound=yes --with-pdumper=yes
>  --with-dumping=pdumper --with-file-notification=yes'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
> IMAGEMAGICK JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
> NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3
> THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
>
> Important settings:
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=ibus
>   locale-coding-system: utf-8-unix
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
>   tooltip-mode: t
>   global-eldoc-mode: t
>   eldoc-mode: t
>   show-paren-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   minibuffer-regexp-mode: t
>   line-number-mode: t
>   indent-tabs-mode: t
>   transient-mark-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort mail-extr emacsbug lisp-mnt mm-archive message sendmail
> yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
> time-date mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode
> mail-utils mule-util cus-edit pp cus-start cus-load wid-edit gnutls
> network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047
> rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny compile
> text-property-search comint ansi-osc ansi-color ring comp-run
> comp-common rx epg rfc6068 epg-config display-line-numbers finder-inf
> package browse-url xdg url url-proxy url-privacy url-expand url-methods
> url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
> url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons
> password-cache json subr-x map byte-opt gv bytecomp byte-compile
> url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
> electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
> term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
> dnd fontset image regexp-opt fringe tabulated-list replace newcomment
> text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
> isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
> font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
> indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
> tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
> romanian slovak czech european ethiopic indian cyrillic chinese
> composite emoji-zwj charscript charprop case-table epa-hook
> jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
> theme-loaddefs faces cus-face macroexp files window text-properties
> overlay sha1 md5 base64 format env code-pages mule custom widget keymap
> hashtable-print-readable backquote threads dbusbind inotify
> dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
> multi-tty move-toolbar make-network-process tty-child-frames
> native-compile emacs)
>
> Memory information:
> ((conses 16 309513 44932) (symbols 48 11458 0) (strings 32 55510 3235)
>  (string-bytes 1 1431141) (vectors 16 20605)
>  (vector-slots 8 250601 12665) (floats 8 225 47)
>  (intervals 56 25047 0) (buffers 992 12))

Message #11 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 76978 <at> debbugs.gnu.org
Subject: Re: bug#76978: 31.0.50; Archive information not displayed for
 installed packages in *Packages* buffer
Date: Sun, 16 Mar 2025 09:21:37 -0400

Philip Kaludercic <philipk <at> posteo.net> writes:

> (Tip: When creating a bug report that you assume specific people are
> interested in, adding a X-Debuggs-CC header will send the people a
> message and add them directly to the CCs.)
>
Got it, thanks for the tip!

> david <davidimagid <at> gmail.com> writes:
>
>> When a package is installed or is a dependency, the "Archive" column in
>> the *Packages* buffer does not display the archive information.  This
>> happens because the function `describe-package-1` in `package.el` skips
>> the Archive section for installed packages due to the following
>> conditional check:
>>
>> (unless (and pkg-dir (not archive)) ; Installed pkgs don't have archive.
>>   (package--print-help-section "Archive"
>>     (or archive "n/a")))
>>
>> The expected behavior is that the "Archive" column should display the
>> archive name (e.g., "gnu", "nongnu", "other unofficial archive") for
>> packages in the installed or dependency status.  This would be helpful
>> because:
>>
>> 1. Traceability: It would allow users to easily identify the source archive
>>    of a package, which is useful for debugging, auditing, and understanding
>>    the package's origin.
>>
>> 2. Security: It would provide users with additional context about the
>>    package's source, helping them make informed decisions about the code
>>    they use.
>>
>> 3. Consistency: Archive information is part of the package metadata, and
>>    displaying it consistently would improve the user experience by making
>>    this information readily available.
>>
>> Currently, the archive information is not displayed for installed or
>> dependency packages, which makes it harder to track the source of these
>> packages.  This behavior is implemented in the `describe-package-1`
>> function in `package.el`, starting around line 2890.  A review of this
>> behavior would be appreciated to ensure users have access to this helpful
>> metadata.
>
> As mentioned in another thread, my suggestion to solve this issue is to
> track the installation-source in the `package-desc-extras' plist.  This
> seems to be the least invasive approach I can think of, which should be
> simple to implement.
>
> The question then is how and where to display the installation-source?.
>
Agreed, storing the source in `package-desc-extras` is clean and
practical.  Displaying it in the "Archive" column makes sense.  Is there
a development branch for `package.el`, or should I create a feature
branch from `master`?

Message #14 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org
Subject: Re: bug#76978: 31.0.50; Archive information not displayed for
 installed packages in *Packages* buffer
Date: Sun, 16 Mar 2025 13:30:17 +0000

david <davidimagid <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> (Tip: When creating a bug report that you assume specific people are
>> interested in, adding a X-Debuggs-CC header will send the people a
>> message and add them directly to the CCs.)
>>
> Got it, thanks for the tip!
>
>> david <davidimagid <at> gmail.com> writes:
>>
>>> When a package is installed or is a dependency, the "Archive" column in
>>> the *Packages* buffer does not display the archive information.  This
>>> happens because the function `describe-package-1` in `package.el` skips
>>> the Archive section for installed packages due to the following
>>> conditional check:
>>>
>>> (unless (and pkg-dir (not archive)) ; Installed pkgs don't have archive.
>>>   (package--print-help-section "Archive"
>>>     (or archive "n/a")))
>>>
>>> The expected behavior is that the "Archive" column should display the
>>> archive name (e.g., "gnu", "nongnu", "other unofficial archive") for
>>> packages in the installed or dependency status.  This would be helpful
>>> because:
>>>
>>> 1. Traceability: It would allow users to easily identify the source archive
>>>    of a package, which is useful for debugging, auditing, and understanding
>>>    the package's origin.
>>>
>>> 2. Security: It would provide users with additional context about the
>>>    package's source, helping them make informed decisions about the code
>>>    they use.
>>>
>>> 3. Consistency: Archive information is part of the package metadata, and
>>>    displaying it consistently would improve the user experience by making
>>>    this information readily available.
>>>
>>> Currently, the archive information is not displayed for installed or
>>> dependency packages, which makes it harder to track the source of these
>>> packages.  This behavior is implemented in the `describe-package-1`
>>> function in `package.el`, starting around line 2890.  A review of this
>>> behavior would be appreciated to ensure users have access to this helpful
>>> metadata.
>>
>> As mentioned in another thread, my suggestion to solve this issue is to
>> track the installation-source in the `package-desc-extras' plist.  This
>> seems to be the least invasive approach I can think of, which should be
>> simple to implement.
>>
>> The question then is how and where to display the installation-source?.
>>
> Agreed, storing the source in `package-desc-extras` is clean and
> practical.  Displaying it in the "Archive" column makes sense.  

As long as it doesn't get cramped, that should be fine.  Mentioning it
in the describe-package buffer would be useful as well.

>                                                                 Is there
> a development branch for `package.el`, or should I create a feature
> branch from `master`?

There is no special branch, master is fine.

Thanks!

Message #17 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 76978 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: [PATCH] package.el: Add built-in version check and active package
 marking
Date: Tue, 18 Mar 2025 13:38:16 -0400

[Message part 1 (text/plain, inline)]

Hello Philip and Emacs maintainers,

I’m submitting this patch to enhance `describe-package` by adding
information about the currently activated package and improving the
built-in version check.  Since "Other versions" already displays the
current version of the package, I’ve added an "activated" marker to
indicate which version is active in the current Emacs session.

This patch for `package.el` introduces two improvements:

1. Built-in version check: The package menu now compares the built-in
version of a package with the available version.  If the available
version is newer, the status is set to "available"; otherwise, it is
marked as "built-in".  This helps users identify when updates are
available for built-in packages.

2. Activated packages in "Other versions": Packages listed in the
"Other versions" section are now marked with ", activated" if they are
currently active in the Emacs session.  This makes it clear which
versions are in use.

I’d appreciate your feedback and suggestions for installing this patch
into the master branch.

Best regards,
David D.

[0001-package.el-Add-built-in-version-check-and-active-pac.patch (text/x-patch, attachment)]

Message #20 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and active
 package marking
Date: Tue, 18 Mar 2025 14:34:18 -0400

> 1. Built-in version check: The package menu now compares the built-in
> version of a package with the available version.  If the available
> version is newer, the status is set to "available"; otherwise, it is
> marked as "built-in".  This helps users identify when updates are
> available for built-in packages.

[ I can't remember enough of the details about this
  part of the UI to have an opinion on that.  ]

> 2. Activated packages in "Other versions": Packages listed in the
> "Other versions" section are now marked with ", activated" if they are
> currently active in the Emacs session.  This makes it clear which
> versions are in use.

Nice!

The commit message lacks the ChangeLog-style itemized changes.
See further comments below.

Also, I can't see your name in the list of people who signed the
copyright paperwork.  Are you already in the process of doing that?

> @@ -1230,7 +1229,7 @@ package-tar-file-info
>                         ((filename (tar-header-name (car tar-parse-info))))
>                       (let ((dirname (file-name-directory filename)))
>                         ;; The first file can be in a subdir: look for the top.
> -                       (if dirname (loop (directory-file-name dirname))
> +                       (if dirname (cl-loop (directory-file-name dirname))
>                           (file-name-as-directory filename)))))
>           (desc-file (package--description-file dir-name))
>           (tar-desc (tar-get-file-descriptor (concat dir-name desc-file))))

This doesn't look right: `loop` is a locally defined function.

>                                (from (or (package-desc-archive opkg)
> -                                        (if (stringp dir) "installed" dir))))
> +                                        (if (package-desc-dir opkg)
> +                                            "installed" "built-in")))

Any reason you dropped the `stringp` test?

> +                              ;; Check if the package is currently activated and
> +                              ;; matches the described version.
> +                              (activated (and (member (package-desc-name opkg)
> +                                                      package-activated-list)
> +                                              (equal ov (package-desc-version desc)))))

`desc` is not necessarily the package that is currently activated, so
I don't understand the `equal` test here.

Also, AFAICT, this goes past the 80 columns limit, please try and change
the layout to stay within 80 columns.

> -                         (if (not ov) (format "%s" from)
> -                           (format "%s (%s)"
> -                                   (make-text-button (package-version-join ov) nil
> -                                                     'font-lock-face 'link
> -                                                     'follow-link t
> -                                                     'action
> -                                                     (lambda (_button)
> -                                                       (describe-package opkg)))
> -                                   from))))
> +                         (format "%s (%s%s)"
> +                                 (if ov
> +                                     (make-text-button (package-version-join ov) nil
> +                                                       'font-lock-face 'link
> +                                                       'follow-link t
> +                                                       'action
> +                                                       (lambda (_button)
> +                                                         (describe-package opkg)))
> +                                   from)
> +                                 from
> +                                 ;; Append ", activated" if the package is currently
> +                                 ;; activated.
> +                                 (if activated ", activated" ""))))

If `ov` is nil, we'll get FROM displayed twice.  🙁


        Stefan

Message #23 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and active
 package marking
Date: Tue, 18 Mar 2025 18:42:19 +0000

david <davidimagid <at> gmail.com> writes:

> Hello Philip and Emacs maintainers,
>
> I’m submitting this patch to enhance `describe-package` by adding
> information about the currently activated package and improving the
> built-in version check.  Since "Other versions" already displays the
> current version of the package, I’ve added an "activated" marker to
> indicate which version is active in the current Emacs session.
>
> This patch for `package.el` introduces two improvements:
>
> 1. Built-in version check: The package menu now compares the built-in
> version of a package with the available version.  If the available
> version is newer, the status is set to "available"; otherwise, it is
> marked as "built-in".  This helps users identify when updates are
> available for built-in packages.
>
> 2. Activated packages in "Other versions": Packages listed in the
> "Other versions" section are now marked with ", activated" if they are
> currently active in the Emacs session.  This makes it clear which
> versions are in use.
>
> I’d appreciate your feedback and suggestions for installing this patch
> into the master branch.
>
> Best regards,
> David D.
>
> From 8b552c182a0ba103fcad89f80abd4343b69bef9a Mon Sep 17 00:00:00 2001
> From: dimagid <dimagidve <at> gmail.com>
> Date: Tue, 18 Mar 2025 13:02:40 -0400
> Subject: [PATCH] package.el: Add built-in version check and active package
>  marking
>
> This commit introduces two improvements:
>
> 1. Built-in version check: The package menu now compares the built-in
> version of a package with the available version. If the available
> version is newer, the status is set to "available"; otherwise, it is
> marked as "built-in". This helps users identify when an update is
> available for built-in packages.
>
> 2. Activated packages in "Other versions": Packages listed in the "Other
> versions" section are now marked with ", activated" if they are
> currently active in the Emacs session. This provides clarity on which
> versions are in use.

Could you rewrite this to fit the commit message style described in
the CONTRIBUTE file?

> ---
>  lisp/emacs-lisp/package.el | 72 ++++++++++++++++++++++++++++----------
>  1 file changed, 53 insertions(+), 19 deletions(-)
>
> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
> index b9a8dacab15..7a615be2461 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -104,7 +104,7 @@
>  ;; Vinicius Jose Latorre <viniciusjl.gnu <at> gmail.com>
>  ;; Phil Hagelberg <phil <at> hagelb.org>
>  
> -;;; ToDo:
> +;;; TODO:

If possible, avoid unrelated changes in the same patch.

>  
>  ;; - putting info dirs at the start of the info path means
>  ;;   users see a weird ordering of categories.  OTOH we want to
> @@ -117,7 +117,6 @@
>  ;; - give users a way to view a package's documentation when it
>  ;;   only appears in the .el
>  ;; - use/extend checkdoc so people can tell if their package will work
> -;; - "installed" instead of a blank in the status column
>  ;; - tramp needs its files to be compiled in a certain order.
>  ;;   how to handle this?  fix tramp?
>  ;; - maybe we need separate .elc directories for various emacs
> @@ -1230,7 +1229,7 @@ package-tar-file-info
>                         ((filename (tar-header-name (car tar-parse-info))))
>                       (let ((dirname (file-name-directory filename)))
>                         ;; The first file can be in a subdir: look for the top.
> -                       (if dirname (loop (directory-file-name dirname))
> +                       (if dirname (cl-loop (directory-file-name dirname))

Watch out, this is not an occurrence of cl-lib's loop, but the function
bound by named-let!

And also, if it were a instance of the old loop, this should be changed
in a separate patch.

>                           (file-name-as-directory filename)))))
>           (desc-file (package--description-file dir-name))
>           (tar-desc (tar-get-file-descriptor (concat dir-name desc-file))))
> @@ -2977,25 +2976,34 @@ describe-package-1
>          (package--print-email-button author)))
>      (let* ((all-pkgs (append (cdr (assq name package-alist))
>                               (cdr (assq name package-archive-contents))
> -                             (let ((bi (assq name package--builtins)))
> -                               (if bi (list (package--from-builtin bi))))))
> -           (other-pkgs (delete desc all-pkgs)))
> +                             (when-let* ((bi (assq name package--builtins)))

I would prefer `and-let*' here.  Also the change confuses me a bit,
could you clarify what is going on with a comment?

> +                               (list (package--from-builtin bi)))))
> +           (other-pkgs (remove desc all-pkgs)))
>        (when other-pkgs
>          (package--print-help-section "Other versions"
>            (mapconcat (lambda (opkg)
>                         (let* ((ov (package-desc-version opkg))
> -                              (dir (package-desc-dir opkg))
>                                (from (or (package-desc-archive opkg)
> -                                        (if (stringp dir) "installed" dir))))
> -                         (if (not ov) (format "%s" from)
> -                           (format "%s (%s)"
> -                                   (make-text-button (package-version-join ov) nil
> -                                                     'font-lock-face 'link
> -                                                     'follow-link t
> -                                                     'action
> -                                                     (lambda (_button)
> -                                                       (describe-package opkg)))
> -                                   from))))
> +                                        (if (package-desc-dir opkg)
> +                                            "installed" "built-in")))
> +                              ;; Check if the package is currently activated and
> +                              ;; matches the described version.
> +                              (activated (and (member (package-desc-name opkg)
> +                                                      package-activated-list)
> +                                              (equal ov (package-desc-version desc)))))
> +                         (format "%s (%s%s)"
> +                                 (if ov
> +                                     (make-text-button (package-version-join ov) nil
> +                                                       'font-lock-face 'link
> +                                                       'follow-link t
> +                                                       'action
> +                                                       (lambda (_button)
> +                                                         (describe-package opkg)))
> +                                   from)
> +                                 from
> +                                 ;; Append ", activated" if the package is currently
> +                                 ;; activated.
> +                                 (if activated ", activated" ""))))

Will this formatting be clear, and not cause any confusion if there is a
package called "activated"?

>                       other-pkgs ", ")
>            ".")))
>  
> @@ -3640,11 +3648,37 @@ package-status-avail-obso
>  
>  ;;; Package menu printing
>  
> +(defun package-menu--check-built-in-version (pkg)
> +  "Check if PKG is a built-in package and compare versions.
> +Return the appropriate status for PKG."
> +  (let* ((status (package-desc-status pkg))
> +         (name (package-desc-name pkg))
> +         (version (package-desc-version pkg))
> +         ;; Check if the package is built-in by looking it up in
> +         ;; `package--builtins'.
> +         (built-in-pkg (assq name package--builtins))
> +         ;; If the package is built-in, get its version.
> +         (built-in-version (if built-in-pkg
> +                               (package-desc-version
> +                                (package--from-builtin built-in-pkg)))))
> +
> +    ;; If the package is built-in and marked as "available", compare
> +    ;; versions.
> +    (when (and built-in-pkg
> +               (equal status "available"))
> +      ;; If the built-in version is older than the available version,
> +      ;; keep status as "available".  Otherwise, set status to
> +      ;; "built-in".
> +      (if (version-list-< built-in-version version)
> +          (setq status "available")
> +        (setq status "built-in")))
> +    status))

I think you can simplify the code here by just returning the values
directly:

(cond
 ((not (and built-in-pkg (equal status "available")))
  status)
 ((version-list-< built-in-version version)
  "available")
 ("built-in"))

> +
>  (defun package-menu--print-info-simple (pkg)
>    "Return a package entry suitable for `tabulated-list-entries'.
>  PKG is a `package-desc' object.
>  Return (PKG-DESC [NAME VERSION STATUS DOC])."
> -  (let* ((status  (package-desc-status pkg))
> +  (let* ((status (package-menu--check-built-in-version pkg))
>           (face (pcase status
>                   ("built-in"  'package-status-built-in)
>                   ("external"  'package-status-external)
> @@ -3676,7 +3710,7 @@ package-menu--print-info-simple
>                'font-lock-face face)
>              ,(propertize status 'font-lock-face face)
>              ,(propertize (or (package-desc-archive pkg) "")
> -                                    'font-lock-face face)
> +                         'font-lock-face face)

Again, this looks like a unrelated change?

>              ,(propertize (package-desc-summary pkg)
>                           'font-lock-face 'package-description)])))

Message #26 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 76978 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: [PATCH] package.el: Add built-in version check and loaded package
 marking
Date: Tue, 18 Mar 2025 17:57:35 -0400

[Message part 1 (text/plain, inline)]

Hello everyone, this is the corrected patch incorporating suggestions
from Philip and Stefan.  I also changed "activated" to "loaded", as
the latter is more accurate for marking packages in the "Other
versions" section.

I’m submitting this patch to enhance `describe-package` by adding
information about the currently loaded package and improving the
built-in version check.  Since "Other versions" already displays the
current version of the package, I’ve added a "loaded" marker to
indicate which version is loaded in the current Emacs session.

This patch for `package.el` introduces two improvements:

1. The package menu now compares the built-in version of a package
with the available version.  If the available version is newer, the
status is set to "available"; otherwise, it is marked as "built-in".
This helps users identify when updates are available for built-in
packages.

2. Packages listed in the "Other versions" section are now marked with
", loaded" if they are currently loaded in the Emacs session.  This
provides clarity on which versions are in use.

I’d appreciate your feedback and suggestions for integrating this
corrected patch into the master branch.

[0001-package.el-Add-built-in-version-check-and-loaded-pac.patch (text/x-patch, attachment)]

Message #29 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Tue, 18 Mar 2025 18:28:11 -0400

> I also changed "activated" to "loaded", as the latter is more accurate
> for marking packages in the "Other versions" section.

Hmm... the two terms do not mean the same thing.  "Loaded" refers to the
package's `.el` files having been `load`ed, whereas "activated" means
that the package's directory has been added to `load-path` and its
`<PKG>-autoloads.el` file has been loaded.

The variable `package-activated-list` keeps track, as the name suggests,
of packages that have been activated, not loaded.

> (package-menu--check-builtin-version): New function to compare
> built-in and available versions.

You can just say "New function" here.  🙂

> +                             ;; Add built-in packages to the list if they exist.
> +                             (and-let* ((bi (assq name package--builtins)))
> +                               (list (package--from-builtin bi)))))
> +           (other-pkgs (remove desc all-pkgs)))

I didn't see an explanation in the commit message for why you replaced
`delete` with `remove`.  AFAICT, `all-pkgs` is a fresh new list so
`delete` looks safe here (as long as we don't use `all-pkgs` later).

> -                              (from (or (package-desc-archive opkg)
> -                                        (if (stringp dir) "installed" dir))))
> +                    (from (or (package-desc-archive opkg)
> +                              (if (stringp dir) "installed" "built-in")))

With the current code I see "builtin" displayed.  I don't understand
what `dir` does in the current code, but that means I also don't
understand what this change is supposed to do.

> +               (format "%s (%s%s)"
> +                       (if ov
> +                           (make-text-button
> +                            (package-version-join ov) nil
> +                            'font-lock-face 'link
> +                            'follow-link t
> +                            'action
> +                            (lambda (_button)
> +                              (describe-package opkg)))
> +                         "n/a")
> +                       from
> +                       (if loaded ", loaded" ""))))
> +           other-pkgs ", ")

I think when `ov` is nil, we're better off using the same output as
before, i.e. just (format "%s" from).  This said, I can't remember when
this can happen.

Also, I had questions in my previous review and I haven't seen any
answer to them (most importantly about copyright paperwork).


        Stefan

Message #32 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Tue, 18 Mar 2025 19:29:13 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I also changed "activated" to "loaded", as the latter is more accurate
>> for marking packages in the "Other versions" section.
>
> Hmm... the two terms do not mean the same thing.  "Loaded" refers to the
> package's `.el` files having been `load`ed, whereas "activated" means
> that the package's directory has been added to `load-path` and its
> `<PKG>-autoloads.el` file has been loaded.
>
> The variable `package-activated-list` keeps track, as the name suggests,
> of packages that have been activated, not loaded.
>
  Should we mark packages in "Other versions" as "activated" or "loaded"
  (like the GNU ELPA package Marginalia, which shows "Loaded" when
  calling `locate-library`)? Currently, "Other versions" redundantly
  includes the described package. I aim to improve this by indicating if
  the package is in `load-path`, helping users identify active or loaded
  packages. What do you recommend?
  >
> Also, I had questions in my previous review and I haven't seen any
> answer to them (most importantly about copyright paperwork).
>
Yes, I have signed the copyright paperwork. I will carefully review your
suggestions and prepare an updated patch addressing them. Thank you for
your thorough feedback and for keeping an eye on the patch.

Message #35 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Tue, 18 Mar 2025 23:08:29 -0400

>> Hmm... the two terms do not mean the same thing.  "Loaded" refers to the
>> package's `.el` files having been `load`ed, whereas "activated" means
>> that the package's directory has been added to `load-path` and its
>> `<PKG>-autoloads.el` file has been loaded.
>>
>> The variable `package-activated-list` keeps track, as the name suggests,
>> of packages that have been activated, not loaded.
>>
>   Should we mark packages in "Other versions" as "activated" or "loaded"
>   (like the GNU ELPA package Marginalia, which shows "Loaded" when
>   calling `locate-library`)?

AFAICT, that shows whether a given file was loaded or not, so "loaded"
sounds like the right term.

>   Currently, "Other versions" redundantly includes the described
>   package. I aim to improve this by indicating if the package is in
>   `load-path`, helping users identify active or loaded packages.
>   What do you recommend?

Not sure what is the question, but I do think we want to show which
packages are "activated" (or "active").  "Loaded" would be a lot more
difficult: we have a way to test if a given *file* has been
loaded, but when it comes to a *package* the meaning is not even
clear (it may be that some of its files have been loaded but not all).

I'm not completely sure how to figure that out, tho.
`package-activated-list` only gives the name of the packages but not
their version.  In some cases you could look for the `<PKG>-autoloads`
file in `load-history` (and then get the version from the directory name
or from the nearby `<PKG>-pkg.el` file), but that won't work if the
package has been activated via package-quickstart.  Maybe we need to
change the package activation to keep more information about the
activated packages.

>> Also, I had questions in my previous review and I haven't seen any
>> answer to them (most importantly about copyright paperwork).
> Yes, I have signed the copyright paperwork.

Great.  I can't find your name in the FSF's copyright list, for
some reason.  Have you signed very recently (and the FSF's copyright
clerk just hasn't updated the list yet?) or maybe you used another
name/email?  In that last case, please contact the FSF clerk and ask them
to add the email you use habitually (such as the one I'm replying to) to
avoid such problems in the future.


        Stefan

Message #38 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Wed, 19 Mar 2025 07:54:32 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> [...] I do think we want to show which packages are "activated" (or
> "active").
>
I agree.  Using "activated," as initially proposed, seems to be the more
appropriate choice.

I will proceed to update the patch based on the latest suggestions and
feedback.  Below is an example of how the changes would appear in
`describe-package`:


Package marginalia is installed.

     Status: Installed in ‘marginalia-2.0/’. Delete
    Version: 2.0
     Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
     ...
Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632 (melpa).




Package diff-hl is installed.

     Status: Installed in ‘diff-hl-1.10.0/’. Delete
    Version: 1.10.0
     Commit: b80ff9b4a772f7ea000e86fbf88175104ddf9557
     ...
Other versions: 1.10.0 (gnu, activated), 20250317.242 (melpa).




Package track-changes is installed.

     Status: Installed in ‘track-changes-1.4/’. Delete
    Version: 1.4
     Commit: ffb7d656a2c89f86ccd2de51379de9612c7a4aa3
     ...
Other versions: 1.4 (gnu, activated), 1.2 (built-in).




Package faceup is installed.

     Status: Installed in ‘faceup-20170925.1946/’,
             shadowing a built-in package (unsigned). Delete
    Version: 20170925.1946
     Commit: 6c92dad56a133e14e7b27831e1bcf9b3a71ff154
     ...
Other versions: 20170925.1946 (melpa, activated), 0.0.6 (built-in).

Note on the package "faceup."  It is interesting that a built-in
package, when installed via `package-install` and with MELPA added to
`package-archives`, can update to a version from MELPA (no GNU ELPA
version is available for this package).

> [...] please contact the FSF clerk and ask them to add the email you
> use habitually (such as the one I'm replying to) to avoid such
> problems in the future.
>
Will do. Thanks.

Message #41 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Wed, 19 Mar 2025 10:55:35 -0400

> Package marginalia is installed.
>
>      Status: Installed in ‘marginalia-2.0/’. Delete
>     Version: 2.0
>      Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
>      ...
> Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632 (melpa).

IIUC this is a package for which you have two versions installed (1.8
and 2.0), right?

That looks good.

> Package faceup is installed.
>
>      Status: Installed in ‘faceup-20170925.1946/’,
>              shadowing a built-in package (unsigned). Delete
>     Version: 20170925.1946
>      Commit: 6c92dad56a133e14e7b27831e1bcf9b3a71ff154
>      ...
> Other versions: 20170925.1946 (melpa, activated), 0.0.6 (built-in).
>
> Note on the package "faceup."  It is interesting that a built-in
> package, when installed via `package-install` and with MELPA added to
> `package-archives`, can update to a version from MELPA (no GNU ELPA
> version is available for this package).

(Non)GNU ELPA is not treated specially, so yes, that's very much expected.

BTW, maybe "Other versions:" should be changed to "All versions:", since
it includes the currently shown version.  We could also try and skip the
currently shown version, but I'm not sure it would be an improvement
(and would require displaying the corresponding info elsewhere).


        Stefan

Message #44 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 11:03:00 -0400

[Message part 1 (text/plain, inline)]

On Wed, Mar 19, 2025 at 10:59 AM Stefan Monnier via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

> > Package marginalia is installed.
> >
> >      Status: Installed in ‘marginalia-2.0/’. Delete
> >     Version: 2.0
> >      Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
> >      ...
> > Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632
> (melpa).
>
> IIUC this is a package for which you have two versions installed (1.8
> and 2.0), right?
>

With the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76568
duplicates
will be harder to install.

[Message part 2 (text/html, inline)]

Message #47 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 76978 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Wed, 19 Mar 2025 11:32:08 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Package marginalia is installed.
>>
>>      Status: Installed in ‘marginalia-2.0/’. Delete
>>     Version: 2.0
>>      Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
>>      ...
>> Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632 (melpa).
>
> IIUC this is a package for which you have two versions installed (1.8
> and 2.0), right?
>
Yes, correct.

> That looks good.
>
>> Package faceup is installed.
>>
>>      Status: Installed in ‘faceup-20170925.1946/’,
>>              shadowing a built-in package (unsigned). Delete
>>     Version: 20170925.1946
>>      Commit: 6c92dad56a133e14e7b27831e1bcf9b3a71ff154
>>      ...
>> Other versions: 20170925.1946 (melpa, activated), 0.0.6 (built-in).
>>
>> Note on the package "faceup."  It is interesting that a built-in
>> package, when installed via `package-install` and with MELPA added to
>> `package-archives`, can update to a version from MELPA (no GNU ELPA
>> version is available for this package).
>
> (Non)GNU ELPA is not treated specially, so yes, that's very much expected.
>
> BTW, maybe "Other versions:" should be changed to "All versions:", since
> it includes the currently shown version.  We could also try and skip the
> currently shown version, but I'm not sure it would be an improvement
> (and would require displaying the corresponding info elsewhere).
>
Yes, we could change "Other versions" to "All versions".

Keeping the current version in the list is useful because it allows
viewing the archive of the installed package.  Additionally, when using
`describe-package`, it may not be obvious which version is current,
especially if it is not activated.  That's why it's important to clearly
mark which version is "activated".  In my case, when a version is
"activated", it always matches the version in the `load-path` and the
one shown by `locate-library`.

There is still room for improvement in the patch.  So far, we have
implemented a check to propose updates for built-in packages only if
the new version is greater than the current one.  We have also added
the "activated" marker for the package in the `load-path`.  It is not
perfect and could be improved, but I believe it is better than what we
currently have in the master branch.

The `package.el` code, particularly in `describe-package-1`, is quite
complex and ad hoc in my opinion.  It could benefit from modularization
and abstraction of certain logic, such as creating private helper
functions to make the code more maintainable and reusable.  However,
that would be the scope of another patch.

Message #50 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: david <davidimagid <at> gmail.com>, 76978 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Wed, 19 Mar 2025 16:46:24 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Package marginalia is installed.
>>
>>      Status: Installed in ‘marginalia-2.0/’. Delete
>>     Version: 2.0
>>      Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
>>      ...
>> Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632 (melpa).
>
> IIUC this is a package for which you have two versions installed (1.8
> and 2.0), right?
>
> That looks good.

What confuses me is that the non-installed version is activated?  Should
we perhaps add `display-local-help' annotations to explain what is meant?

Message #53 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 76978 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: [PATCH] package.el: Add built-in version check and loaded
 package marking
Date: Wed, 19 Mar 2025 13:25:35 -0400

Philip Kaludercic <philipk <at> posteo.net> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> Package marginalia is installed.
>>>
>>>      Status: Installed in ‘marginalia-2.0/’. Delete
>>>     Version: 2.0
>>>      Commit: c51fd9e4d4258543e0cd8dedda941789163bec5a
>>>      ...
>>> Other versions: 1.8 (installed), 2.0 (gnu, activated), 20250317.1632 (melpa).
>>
>> IIUC this is a package for which you have two versions installed (1.8
>> and 2.0), right?
>>
>> That looks good.
>
> What confuses me is that the non-installed version is activated?  Should
> we perhaps add `display-local-help' annotations to explain what is meant?

The version 2.0 is indeed installed, as shown by the "Status" line.
This is the help buffer displayed when calling `describe-package` on the
GNU ELPA version 2.0 of Marginalia.

I am still working on the patch to improve how this information is
displayed, ensuring it is clear and avoids confusion.  Suggestions like
renaming "Other versions" to "All versions" and adding contextual
explanations are being considered.

Message #56 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 16:26:01 -0400

> With the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76568
> duplicates will be harder to install.

They're still easy to have (e.g. install some packages system-wide and
then let the users install other versions in their home dir), and that's
a good thing: we want to support setups with several versions installed
at the same time.  Of course, users usually don't want that, so it's
good to make sure it doesn't happen by accident.  In any case, my
question was simply to confirm that I understood correctly the
information that's displayed.


        Stefan

Message #59 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 16:36:54 -0400

[Message part 1 (text/plain, inline)]

On Wed, Mar 19, 2025 at 16:26 Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> > With the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76568
> > duplicates will be harder to install.
>
> They're still easy to have (e.g. install some packages system-wide and
> then let the users install other versions in their home dir), and that's
> a good thing: we want to support setups with several versions installed
> at the same time.  Of course, users usually don't want that, so it's
> good to make sure it doesn't happen by accident.  In any case, my
> question was simply to confirm that I understood correctly the
> information that's displayed.


Maybe I should change the patch to prompt for allowing a dupe install if
that's what someone wants?

[Message part 2 (text/html, inline)]

Message #62 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 16:45:44 -0400

[Message part 1 (text/plain, inline)]

No
On Wed, Mar 19, 2025 at 16:36 Ship Mints <shipmints <at> gmail.com> wrote:

>
> On Wed, Mar 19, 2025 at 16:26 Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>
>> > With the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76568
>> > duplicates will be harder to install.
>>
>> They're still easy to have (e.g. install some packages system-wide and
>> then let the users install other versions in their home dir), and that's
>> a good thing: we want to support setups with several versions installed
>> at the same time.  Of course, users usually don't want that, so it's
>> good to make sure it doesn't happen by accident.  In any case, my
>> question was simply to confirm that I understood correctly the
>> information that's displayed.
>
>
> Maybe I should change the patch to prompt for allowing a dupe install if
> that's what someone wants?
>

Hmm. Maybe it already does. Not at my computer.

>

[Message part 2 (text/html, inline)]

Message #65 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 17:22:18 -0400

> Maybe I should change the patch to prompt for allowing a dupe install if
> that's what someone wants?

Not sure it's worth the trouble.  It's a sufficiently rare situation.


        Stefan

Message #68 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 17:47:09 -0400

[Message part 1 (text/plain, inline)]

On Wed, Mar 19, 2025 at 5:22 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> > Maybe I should change the patch to prompt for allowing a dupe install if
> > that's what someone wants?
>
> Not sure it's worth the trouble.  It's a sufficiently rare situation.
>

I wish that were true.  I've gone through using the "install" feature from
the package-list and description screen only to find that it duped because
I didn't specifically run package-upgrade on each package.  Most of the
people I work with don't even bother to read it and just select install
from the same screen.  It's a design issue I didn't address but I did at
least address an already-installed warning.

We should get that patch going.

[Message part 2 (text/html, inline)]

Message #71 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 18:08:08 -0400

>> > Maybe I should change the patch to prompt for allowing a dupe install if
>> > that's what someone wants?
>> Not sure it's worth the trouble.  It's a sufficiently rare situation.
> I wish that were true.

I think you misunderstood.  What I think is rare is the desire/need to
install two different versions at the same time.


        Stefan

Message #74 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 18:13:02 -0400

[Message part 1 (text/plain, inline)]

On Wed, Mar 19, 2025 at 6:08 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:

> >> > Maybe I should change the patch to prompt for allowing a dupe install
> if
> >> > that's what someone wants?
> >> Not sure it's worth the trouble.  It's a sufficiently rare situation.
> > I wish that were true.
>
> I think you misunderstood.  What I think is rare is the desire/need to
> install two different versions at the same time.
>

Agree.  And backing out to an older version is just a reinstall and restart
away...assuming the user remembers which version they had before.  Perhaps
package.el could use an install log users can consult.

[Message part 2 (text/html, inline)]

Message #77 received at 76978 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76978 <at> debbugs.gnu.org, david <davidimagid <at> gmail.com>,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76978: [PATCH] package.el: Add built-in version check and
 loaded package marking
Date: Wed, 19 Mar 2025 18:20:07 -0400

> Agree.  And backing out to an older version is just a reinstall and restart
> away...assuming the user remembers which version they had before.  Perhaps
> package.el could use an install log users can consult.

Maybe I did include a prompt before deleting a package because it's
difficult to be sure that the directory we're deleting contains really
only the original files untouched, so there's a risk that we could
delete information that the user cannot easily reproduce.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.