Am Montag, dem 07.10.2024 um 16:56 +0200 schrieb Martin Edström: > 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. There are opposite goals to "make sure that the file hasn't been tampered with" (upstream) and "to keep files patchable" (Guix). I don't think we can easily satisfy both. Perhaps we could use the original store path as some kind of key to match the files (since we compile them in-store IIRC), but that wouldn't work for the "let's compile our init.el" use case.
As a matter of fact, we've disabled JIT compilation for the very reason that stuff can break ;) > 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. What about aggressive-recompilation-on-write? > 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? We write store paths to a subdirs.el – unless specifically prompted to reload that, Emacs will keep using old libraries. This is by design, so that updating Emacs does not cause any issues with (byte) compiled files. > 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. Since all timestamps point to 1970, you are right, `load-prefer-newer' does nothing. Cheers
