GNU bug report logs - #79411
31.0.50; describe-package does not show :readme after package installation, but sth else

Previous Next

To reply to this bug, email your comments to 79411 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: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; describe-package does not show :readme after package
 installation, but sth else
Date: Mon, 8 Sep 2025 22:18:43 +0200

X-Debbugs-Cc: Philip Kaludercic <philipk <at> posteo.net>

Move your `package-user-dir' temporarily away.  Then start "./src/emacs
-Q".  Then:

M-x package-initialize RET
M-x package-list-packages RET
C-h P beframe RET

This shows the README.md as package description, as defined by
Prots through property :readme:

  # Beframe (beframe.el) for GNU Emacs

  `beframe` enables a frame-oriented Emacs workflow where each frame has
  access to the list of buffers visited therein.  In the interest of
  brevity, we call buffers that belong to frames "beframed".

  **Video demo:** <https://protesilaos.com/codelog/2023-02-28-emacs-beframe-demo/>

  + Package name (GNU ELPA): `beframe`
  + Official manual: <https://protesilaos.com/emacs/beframe>
  + Change log: <https://protesilaos.com/emacs/beframe-changelog>
  + Git repositories:
    + GitHub: <https://github.com/protesilaos/beframe>
    + GitLab: <https://gitlab.com/protesilaos/beframe>
  + Backronym: Buffers Encapsulated in Frames Realise Advanced
    Management of Emacs.

Then:

M-x package-install beframe RET
C-h P beframe RET

Now this shows the README.org file as package description, which
in that place is ... ugly.  I am aware of the following comment
in function `package--get-description':

  ;; We don’t include README.md here, because that is often the home
  ;; page on a site like github, and not suitable as the package long
  ;; description.

But probably if a package author has willfully designed her/his
README.md to be used as property :readme, then it should also be
used for installed packages [1]?  Probably if there is a :readme
property, then function `package--get-description' should even
always use that, and not resort to guessing [2]?

If you agree and want me to provide a patch to that effect ([1]
or [2]?), please let me know.

[ I'm filing/asking this because I have been planning to use a
  combination of (:readme "README.md" :doc "README.org") similar
  to what Prots has been doing for his beframe package. ]

In GNU Emacs 31.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2025-09-08 built on sappc2
Repository revision: 4c74b68fb1f23db6ba770f7322efe378f3492751
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-native-compilation --with-mailutils'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3
ZLIB

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_TIME: POSIX
  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 transient pcase format-spec edmacro
kmacro warnings info beframe-autoloads easy-mmode loaddefs-gen tar-mode
arc-mode archive-mode novice cus-edit pp cus-start cus-load wid-edit
lisp-mnt misearch multi-isearch cl-extra cl-print help-fns radix-tree
help-mode 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 gnutls
network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny epg rfc6068
epg-config display-line-numbers compile text-property-search comint
ansi-osc ansi-color ring comp-run comp-common rx finder-inf thingatpt
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/x-win x-win term/common-win x-dnd touch-screen 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 lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames native-compile emacs)

Memory information:
((conses 16 348941 46086) (symbols 48 13566 0) (strings 32 67396 5547)
 (string-bytes 1 1770646) (vectors 16 33740)
 (vector-slots 8 746562 66527) (floats 8 61 158)
 (intervals 56 25221 0) (buffers 984 16))

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: debbugs-submit <at> debbugs.gnu.org, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme after package installation, but sth else
Date: Mon, 08 Sep 2025 20:56:36 +0000

Hi, if you have a reasonable patch, I would gladly review it.  The behaviour you describe does fundamentally sound confusing, and it would be nice to come up with a solution.

On 8 September 2025 22:18:43 CEST, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de> wrote:
>X-Debbugs-Cc: Philip Kaludercic <philipk <at> posteo.net>
>
>Move your `package-user-dir' temporarily away.  Then start "./src/emacs
>-Q".  Then:
>
>M-x package-initialize RET
>M-x package-list-packages RET
>C-h P beframe RET
>
>This shows the README.md as package description, as defined by
>Prots through property :readme:
>
>  # Beframe (beframe.el) for GNU Emacs
>
>  `beframe` enables a frame-oriented Emacs workflow where each frame has
>  access to the list of buffers visited therein.  In the interest of
>  brevity, we call buffers that belong to frames "beframed".
>
>  **Video demo:** <https://protesilaos.com/codelog/2023-02-28-emacs-beframe-demo/>
>
>  + Package name (GNU ELPA): `beframe`
>  + Official manual: <https://protesilaos.com/emacs/beframe>
>  + Change log: <https://protesilaos.com/emacs/beframe-changelog>
>  + Git repositories:
>    + GitHub: <https://github.com/protesilaos/beframe>
>    + GitLab: <https://gitlab.com/protesilaos/beframe>
>  + Backronym: Buffers Encapsulated in Frames Realise Advanced
>    Management of Emacs.
>
>Then:
>
>M-x package-install beframe RET
>C-h P beframe RET
>
>Now this shows the README.org file as package description, which
>in that place is ... ugly.  I am aware of the following comment
>in function `package--get-description':
>
>  ;; We don’t include README.md here, because that is often the home
>  ;; page on a site like github, and not suitable as the package long
>  ;; description.
>
>But probably if a package author has willfully designed her/his
>README.md to be used as property :readme, then it should also be
>used for installed packages [1]?  Probably if there is a :readme
>property, then function `package--get-description' should even
>always use that, and not resort to guessing [2]?
>
>If you agree and want me to provide a patch to that effect ([1]
>or [2]?), please let me know.
>
>[ I'm filing/asking this because I have been planning to use a
>  combination of (:readme "README.md" :doc "README.org") similar
>  to what Prots has been doing for his beframe package. ]
>
>In GNU Emacs 31.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.16.0) of 2025-09-08 built on sappc2
>Repository revision: 4c74b68fb1f23db6ba770f7322efe378f3492751
>Repository branch: master
>Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
>System Description: Debian GNU/Linux 12 (bookworm)
>
>Configured using:
> 'configure --with-native-compilation --with-mailutils'
>
>Configured features:
>ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
>LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
>NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
>TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3
>ZLIB
>
>Important settings:
>  value of $LC_COLLATE: POSIX
>  value of $LC_TIME: POSIX
>  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 transient pcase format-spec edmacro
>kmacro warnings info beframe-autoloads easy-mmode loaddefs-gen tar-mode
>arc-mode archive-mode novice cus-edit pp cus-start cus-load wid-edit
>lisp-mnt misearch multi-isearch cl-extra cl-print help-fns radix-tree
>help-mode 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 gnutls
>network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047
>rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny epg rfc6068
>epg-config display-line-numbers compile text-property-search comint
>ansi-osc ansi-color ring comp-run comp-common rx finder-inf thingatpt
>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/x-win x-win term/common-win x-dnd touch-screen 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 lcms2
>dynamic-setting system-font-setting font-render-setting cairo gtk
>x-toolkit xinput2 x multi-tty move-toolbar make-network-process
>tty-child-frames native-compile emacs)
>
>Memory information:
>((conses 16 348941 46086) (symbols 48 13566 0) (strings 32 67396 5547)
> (string-bytes 1 1770646) (vectors 16 33740)
> (vector-slots 8 746562 66527) (floats 8 61 158)
> (intervals 56 25221 0) (buffers 984 16))
>
>
>

Sent from my phone

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Philip Kaludercic <philipk <at> posteo.net>, 79411 <at> debbugs.gnu.org
Cc: Stephen Leake <stephen_leake <at> stephe-leake.org>
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme after
 package installation, but sth else
Date: Tue, 9 Sep 2025 14:00:34 +0200

On 2025-09-08  22:56, Philip Kaludercic wrote:

> Hi, if you have a reasonable patch, I would gladly review it. The
> behaviour you describe does fundamentally sound confusing, and it
> would be nice to come up with a solution.

Thanks for your quick reply and for caring about ELPA, package.el, and
the packaging system in general!

Only having a "reasonable" solution is more difficult than I initially
thought ... I started edebugging and eyeballing that code only after
filing this bug, sorry.

So here are some facts, not to lecture you, but to have them summarized
and probably corrected, if I got them wrong:

- I have been hoping on the ELPA metadata, like, :news, :doc:, :readme
  etc., but that's not part of the archive web server contract (as in
  (elisp) Archive Web Server).

  The only thing we can get from an archive web server to help with this
  issue is file <package name>-readme.txt.

- For the following reasons it is not reasonable to access that file
  online *for installed packages*:

  + The user might be offline.
  + A package, once installed, forgets about its originating archive,
    and determining a matching archive might be difficult.
  + The file on the archive web server is not versioned, so it might not
    match the version of the installed package.

- So the only thing that seems reasonable is to download <package
  name>-readme.txt during package installation and store it below
  `package-user-dir'.  And remove it during package deinstallation.

Well, and Emacs did exactly that already until commit
d4fb2690702fbd348977fc94a9f7a99c00cc3010 removed it.  Does anybody have
an idea as to why that was removed?  (CCing Stephen, the author of that
commit.)  The commit message does not quote a bug number, and the only
bug I have found that might be related to this issue is bug#39609, which
seems to be a duplicate of this one.

Please advise how to continue here.  I can live with this issue and, as
a work-around for my package, prepare file "README-elpa.md" as a copy of
my "README.md" when ELPA processes the :make property.  (That should
work, shouldn't it?)

Thanks!

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Stephen Leake <stephen_leake <at> stephe-leake.org>,
 Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>, 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme
 after package installation, but sth else
Date: Thu, 11 Sep 2025 21:38:28 +0000

Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> On 2025-09-08  22:56, Philip Kaludercic wrote:
>
>> Hi, if you have a reasonable patch, I would gladly review it. The
>> behaviour you describe does fundamentally sound confusing, and it
>> would be nice to come up with a solution.
>
> Thanks for your quick reply and for caring about ELPA, package.el, and
> the packaging system in general!

Thanks!  And sorry for the delay this time around, I didn't have access
to my laptop until now :)

> Only having a "reasonable" solution is more difficult than I initially
> thought ... I started edebugging and eyeballing that code only after
> filing this bug, sorry.
>
> So here are some facts, not to lecture you, but to have them summarized
> and probably corrected, if I got them wrong:
>
> - I have been hoping on the ELPA metadata, like, :news, :doc:, :readme
>   etc., but that's not part of the archive web server contract (as in
>   (elisp) Archive Web Server).
>
>   The only thing we can get from an archive web server to help with this
>   issue is file <package name>-readme.txt.
>
> - For the following reasons it is not reasonable to access that file
>   online *for installed packages*:
>
>   + The user might be offline.
>   + A package, once installed, forgets about its originating archive,
>     and determining a matching archive might be difficult.
>   + The file on the archive web server is not versioned, so it might not
>     match the version of the installed package.

100% agree here.

> - So the only thing that seems reasonable is to download <package
>   name>-readme.txt during package installation and store it below
>   `package-user-dir'.  And remove it during package deinstallation.
>
> Well, and Emacs did exactly that already until commit
> d4fb2690702fbd348977fc94a9f7a99c00cc3010 removed it.  Does anybody have
> an idea as to why that was removed?  (CCing Stephen, the author of that
> commit.)  The commit message does not quote a bug number, and the only
> bug I have found that might be related to this issue is bug#39609, which
> seems to be a duplicate of this one.

On a quick glance, I cannot see the reason either.  But it seems like
the reasonable approach, and I don't see a reason why we shouldn't be
able to revert that part of the commit.

> Please advise how to continue here.  I can live with this issue and, as
> a work-around for my package, prepare file "README-elpa.md" as a copy of
> my "README.md" when ELPA processes the :make property.  (That should
> work, shouldn't it?)

I would like to avoid :make properties in package specifications.  To
build on your last suggestion, we can just make package.el download the
-readme.txt as README-elpa in the package directory (if it doesn't
already exist).  This would also have the advantage of not complicating
the cleanup procedure, as removing the directory would automatically
clean up the README file.

> Thanks!

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

From: Stephen Leake <stephen_leake <at> stephe-leake.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: "Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>,
 Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>, 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme
 after package installation, but sth else
Date: Thu, 11 Sep 2025 15:53:34 -0700

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

>> Well, and Emacs did exactly that already until commit
>> d4fb2690702fbd348977fc94a9f7a99c00cc3010 removed it.  Does anybody have
>> an idea as to why that was removed?  (CCing Stephen, the author of that
>> commit.)  The commit message does not quote a bug number, and the only
>> bug I have found that might be related to this issue is bug#39609, which
>> seems to be a duplicate of this one.
>
> On a quick glance, I cannot see the reason either.  But it seems like
> the reasonable approach, and I don't see a reason why we shouldn't be
> able to revert that part of the commit.

I don't really remember, but I think the problem was there were old
readme's hanging around, and the local file was prefered over network
access, so when you asked for the readme for a package, you got the
wrong one.

If you can _guarrantee_ that the file is deleted when it's old, that
would be ok. But that's pretty hard to do.

-- 
-- Stephe

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stephen Leake <stephen_leake <at> stephe-leake.org>
Cc: "Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>,
 Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>, 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme
 after package installation, but sth else
Date: Fri, 12 Sep 2025 09:23:41 +0000

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

Stephen Leake <stephen_leake <at> stephe-leake.org> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>>> Well, and Emacs did exactly that already until commit
>>> d4fb2690702fbd348977fc94a9f7a99c00cc3010 removed it.  Does anybody have
>>> an idea as to why that was removed?  (CCing Stephen, the author of that
>>> commit.)  The commit message does not quote a bug number, and the only
>>> bug I have found that might be related to this issue is bug#39609, which
>>> seems to be a duplicate of this one.
>>
>> On a quick glance, I cannot see the reason either.  But it seems like
>> the reasonable approach, and I don't see a reason why we shouldn't be
>> able to revert that part of the commit.
>
> I don't really remember, but I think the problem was there were old
> readme's hanging around, and the local file was prefered over network
> access, so when you asked for the readme for a package, you got the
> wrong one.
>
> If you can _guarrantee_ that the file is deleted when it's old, that
> would be ok. But that's pretty hard to do.

In my previous message I suggested something like:

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ba9999c20e6..b9e2eb96389 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2162,7 +2162,15 @@ package-install-from-archive
                ;; Update the new (activated) pkg-desc as well.
                (when-let* ((pkg-descs (cdr (assq (package-desc-name pkg-desc)
                                                  package-alist))))
-                 (setf (package-desc-signed (car pkg-descs)) t))))))))))
+                 (setf (package-desc-signed (car pkg-descs)) t)))))))
+      ;; fetch a backup of the readme file from the server
+      (let ((readme (expand-file-name "README-elpa" (package-desc-dir pkg-desc))))
+        (unless (file-readable-p readme)
+          (package--with-response-buffer (package-archive-base pkg-desc)
+            :file (format "%s-readme.txt" (package-desc-name pkg-desc))
+            :noerror t
+            (write-region nil nil readme)))))))
+
 
 ;;;###autoload
 (defun package-installed-p (package &optional min-version)

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

As we store the README file inside the package directory, it should also
be deleted when we delete the package -- unless I am missing something?

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Philip Kaludercic <philipk <at> posteo.net>,
 Stephen Leake <stephen_leake <at> stephe-leake.org>
Cc: 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme after
 package installation, but sth else
Date: Sat, 13 Sep 2025 12:04:04 +0200

On 2025-09-12  11:23, Philip Kaludercic wrote:

> In my previous message I suggested something like:
> 
> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
> index ba9999c20e6..b9e2eb96389 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -2162,7 +2162,15 @@ package-install-from-archive
>                 ;; Update the new (activated) pkg-desc as well.
>                 (when-let* ((pkg-descs (cdr (assq (package-desc-name pkg-desc)
>                                                   package-alist))))
> -                 (setf (package-desc-signed (car pkg-descs)) t))))))))))
> +                 (setf (package-desc-signed (car pkg-descs)) t)))))))
> +      ;; fetch a backup of the readme file from the server
> +      (let ((readme (expand-file-name "README-elpa" (package-desc-dir pkg-desc))))
> +        (unless (file-readable-p readme)
> +          (package--with-response-buffer (package-archive-base pkg-desc)
> +            :file (format "%s-readme.txt" (package-desc-name pkg-desc))
> +            :noerror t
> +            (write-region nil nil readme)))))))
> +
>  
>  ;;;###autoload
>  (defun package-installed-p (package &optional min-version)
> 
> As we store the README file inside the package directory, it should also
> be deleted when we delete the package -- unless I am missing something?

I like that approach, it should fix this issue, and it nicely
complements what elpa-admin.el already does for some readmes on server
side.  Some notes:

1. You probably should not write README-elpa when it would be empty
   (which can happen, see
   https://elpa.gnu.org/packages/bicep-ts-mode-readme.txt), as that
   would block the search of `package--get-description' for more
   readmes.

2. Alternatively or in addition, one could extend
   `package--get-description' to not consider empty files in its
   search for a readme.

3. I think a paragraph in "(elisp) Packaging Basics" and some tests in
   package-tests.el would still be required.  Do you want me to supply
   these?

Thanks!

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Stephen Leake <stephen_leake <at> stephe-leake.org>, 79411 <at> debbugs.gnu.org
Subject: Re: bug#79411: 31.0.50; describe-package does not show :readme
 after package installation, but sth else
Date: Sat, 13 Sep 2025 10:39:36 +0000

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

Jens Schmidt <jschmidt4gnu <at> vodafonemail.de> writes:

> On 2025-09-12  11:23, Philip Kaludercic wrote:
>
>> In my previous message I suggested something like:
>> 
>> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
>> index ba9999c20e6..b9e2eb96389 100644
>> --- a/lisp/emacs-lisp/package.el
>> +++ b/lisp/emacs-lisp/package.el
>> @@ -2162,7 +2162,15 @@ package-install-from-archive
>>                 ;; Update the new (activated) pkg-desc as well.
>>                 (when-let* ((pkg-descs (cdr (assq (package-desc-name pkg-desc)
>>                                                   package-alist))))
>> -                 (setf (package-desc-signed (car pkg-descs)) t))))))))))
>> +                 (setf (package-desc-signed (car pkg-descs)) t)))))))
>> +      ;; fetch a backup of the readme file from the server
>> +      (let ((readme (expand-file-name "README-elpa" (package-desc-dir pkg-desc))))
>> +        (unless (file-readable-p readme)
>> +          (package--with-response-buffer (package-archive-base pkg-desc)
>> +            :file (format "%s-readme.txt" (package-desc-name pkg-desc))
>> +            :noerror t
>> +            (write-region nil nil readme)))))))
>> +
>>  
>>  ;;;###autoload
>>  (defun package-installed-p (package &optional min-version)
>> 
>> As we store the README file inside the package directory, it should also
>> be deleted when we delete the package -- unless I am missing something?
>
> I like that approach, it should fix this issue, and it nicely
> complements what elpa-admin.el already does for some readmes on server
> side.  Some notes:
>
> 1. You probably should not write README-elpa when it would be empty
>    (which can happen, see
>    https://elpa.gnu.org/packages/bicep-ts-mode-readme.txt), as that
>    would block the search of `package--get-description' for more
>    readmes.
>
> 2. Alternatively or in addition, one could extend
>    `package--get-description' to not consider empty files in its
>    search for a readme.

I think the former is preferable.  My suggestion would be as follows:

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ba9999c20e6..0885f1a5a35 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2162,7 +2162,18 @@ package-install-from-archive
                ;; Update the new (activated) pkg-desc as well.
                (when-let* ((pkg-descs (cdr (assq (package-desc-name pkg-desc)
                                                  package-alist))))
-                 (setf (package-desc-signed (car pkg-descs)) t))))))))))
+                 (setf (package-desc-signed (car pkg-descs)) t)))))))
+      ;; fetch a backup of the readme file from the server
+      (let ((readme (expand-file-name "README-elpa" (package-desc-dir pkg-desc))))
+        (unless (file-readable-p readme)
+          (package--with-response-buffer (package-archive-base pkg-desc)
+            :file (format "%s-readme.txt" (package-desc-name pkg-desc))
+            :noerror t
+            (unless (save-excursion
+                      (goto-char (point-min))
+                      (looking-at-p "\\`[[:space:]]*\\'"))
+              (write-region nil nil readme))))))))
+
 
 ;;;###autoload
 (defun package-installed-p (package &optional min-version)

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

> 3. I think a paragraph in "(elisp) Packaging Basics" and some tests in
>    package-tests.el would still be required.  Do you want me to supply
>    these?

That would be great!

> Thanks!

Previous Next

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