GNU bug report logs - #73681
Maybe partly undo the patch on Elisp comp-el-to-eln-filename

Previous Next

Full log

View this message in rfc822 format

From: "Martin Edström" <meedstrom <at> runbox.eu>
To: 73681 <at> debbugs.gnu.org
Cc: "liliana.prikler" <liliana.prikler <at> gmail.com>
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Date: Mon, 07 Oct 2024 16:56:50 +0200 (CEST)

Hi, I suggest to maybe amend one of the things done by this patchset:  https://issues.guix.gnu.org/67260

It undoes the hashing effect of the Elisp function `comp-el-to-eln-filename`, and that seems likely to cause issues downstream, for example in my Emacs package: https://github.com/meedstrom/org-node/issues/60.

To summarize: that function is supposed to generate a filename with a hash based not only the filename but the contents of the file.  While it makes sense in Guix to ignore the contribution of the filename, I believe it should still output a new filename when the contents change.

Otherwise there seems to be no way for a downstream package to ensure that it is using an up-to-date .eln variant of an .el file.

I may have missed something though.  Can someone in the know tell me what happens if you have not updated Emacs (which if I understand correctly, means ELN-DIR does not change), but you do update an Elisp package, whether through Guix or through Emacs' own package managers. Will Emacs then possibly load an old .eln?  

I do not believe that user options like `load-prefer-newer` would affect it. It would just rely on running the aforementioned function and counting on it to output an .eln filename that does not exist if the source is newer.

Previous Next

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