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

Previous Next

Full log

View this message in rfc822 format

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: bug#76978: [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.

Previous Next

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