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

[Liliana Marie Prikler]

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