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

[Martin Edström]

On Tue, 08 Oct 2024 06:32:32 +0200, Liliana Marie Prikler 
<liliana.prikler@gmail.com> wrote:

> Could you keep track of modifications to org-node-parser and recompile
> that on change?  Or is it part of your package already – if the latter,
> then we should already have it compiled as a package.

It comes as part of the package. I don't want to assume that it has been 
compiled, since it's fairly performance-sensitive. That's why I'll either use a 
previously existing compiled object or make a new one.

What I'm getting from this is that it might be safer to just compile the object 
into /tmp and use that, regardless of what may already exist.  At the moment, 
that's necessary for keeping the option open of using an .eln on Guix.

So let's ignore my package, it is just an example of a downstream use of 
`comp-el-to-eln-filename` that relied on its hashing functionality.

Let's just discuss that function.

I have to point out that the emacs `load-path` does not include any native 
paths.  When I inspect the value on my non-Guix emacs, I see no references to 
.../eln-cache/..., just references to directories where there are .elc and .el 
files.

I infer that Emacs starts with finding a library in load-path, then converts 
the path with `comp-el-to-eln-filename`, and checks if that file exists, then 
loads it.

And crucially, it is not just about the filepath, the function hashes the file 
contents as well. That ensures that the output path is always different if the 
source file changes.

Since Guix has a patch that removes this effect, it seems like a package could 
be upgraded many, many times, without the .eln path ever changing, and so the 
user would stay on that very outdated file.

Is that not a regression/bug?