ELPA packages are fetched from unstable url -> not reproducible

[jorsn]

Elpa compresses all but the newest versions of a package and keeps compressed archives only of around 20 hand-selected versions. They also keep all packages in their git repo, which is a complete archive.

Details: NixOS/nixpkgs#110796

[kennyballou]

I've been thinking about this issue on and off... And since there's several different issue threads in three different repositories, I'm not sure where to post this to get the right people engaged, sorry for the CC spam: @talyz, @spacekitteh, @ttuegel. Please bring anyone else in if I missed anyone.

One of the proposed solutions in this thread was to fetch the sources from elpa git instead of downloading from the current version as published by the elpa packages file. Would this approach be acceptable? The complexities of the archive pruning that elpa does makes the stable link outside of git seem questionable. Furthermore, I think this avoids a lot of complexities regarding special cases in emacs2nix or post processing steps that might happen in the overlay or in nixpkgs directly.

Thoughts?

See also: NixOS/nixpkgs#110796
nix-community/emacs-overlay#125

[Radvendii]

I haven't tested it yet, but this PR claims to fix the issue: NixOS/nixpkgs#132937

Should we close this?

[kennyballou]

I think the functionality of NixOS/nixpkgs#132937 certainly warrants the closure of this issue. However, I notice that this does not mean all past archive builds of ELPA will be reproducible. Notably, the thread on GNU ELPA mentions that they don't keep every previous version. Making this issue so difficult is the schedule for keeping and removing older versions is not uniform. That said, I'm not sure that's of any consequence. Perhaps we can address that later if people need/want the ability to reproducible arbitrarily old versions of ELPA packages.

tl;dr: I vote to close this issue with the warning that the underlying problem likely still exists but is much harder to trigger (likely years hard).

[jorsn]

tl;dr: I vote to close this issue with the warning that the underlying problem likely still exists but is much harder to trigger (likely years hard).

Rather one year hard, if you look at the version history kept in the archive, e.g. for auctex: http://elpa.gnu.org/packages/auctex.html
One year ist not too much. You can basically say that every dev env/nix shell involving emacs will probably fail to build if it is using one year old nixpkgs. If nixpkgs are two years old, then it will most certainly fail. This is not much of determinism, and when I have deadlines, e.g. writing a paper, it is strictly prohibitive to update emacs if that means updating settings. It just happened to me: I suddenly couldn't build the dev env any more, because emacs packages were failing to be fetched, and for the new emacs I had to change settings. Fortunately the deadline is still two weaks ahead.

I'd vode to reopen all the related issues, but unfortunately I have no time for implementing something, currently.
Note that I have implemented the core/proof of concept of git-based fetching in NixOS/nixpkgs#110796, although in elisp.
The easiest solution is probably to fetch from archive.org, as we do in nixpkgs for printer drivers. Then, it is really unlikely that a package will disappear in the next years.

[kennyballou]

As hinted, the larger question seems to be: does "Reproducible builds and deployments."[0] have a limit? Is there some asterisk missing from that statement? OR, is there no limit and we, as a community, mean that statement for all packages that ever make it into the mainline tree? (<- this is probably something already answered or needs to be asked against a wider audience.)

I worry about depending on archive.org links because they may not index ELPA packages. For example, I wanted to see if the oldest version of auctex was hosted on the wayback machine. Turns out, it is not hosted.

I would like to see a git based solution directly on the repo of ELPA (granted, ELPA maintainers may start hating us for that?) as this seems to be the most stable and reproducible. Downsides, this solution is also likely not going to work to infinity and beyond.

I may dig around on this, but I won't have a lot of time until next year maybe.

[jorsn]

What about this git-based solution here: NixOS/nixpkgs#110796 (comment)