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

Previous Next

Full log

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Martin Edström <meedstrom <at> runbox.eu>, 
 73681 <at> debbugs.gnu.org
Subject: Re: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Date: Mon, 07 Oct 2024 20:02:17 +0200

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

Previous Next

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