Can clojure builds be reproducible? (new Debian forky requirement)

Question

Debian now requires packages to be reproducible: https://lists.debian.org/debian-devel-announce/2026/05/msg00001.html and I thought I recalled that compilation, at least, couldn't produce reproducible output (e.g. with respect to variable naming in the class files), and some testing suggests that might still be the case (tested with 1.12.0 via https://diffoscope.org/).

I assume that for Clojure related packages to remain in the next Debian release, we'll need to address the requirement one way or another, if we can, so I wanted to ask about the situation upstream first.

Offhand, I think the main concern is with AOT compilation, which Debian only uses for "leaf" applications, packaged as an uberjar (e.g. leiningen, puppetserver, puppetdb, etc.), and Debian already has infrastructure to make sure that jars are otherwise reproducible (with respect to timestamps, etc.), so the issue there is mostly "just" regarding the file content.

Thanks

Answer 1

AOT and uberjars are orthogonal. You can still have a "leaf" app packaged neatly in an uberjar and without any AOT - it will be reproducible because it's just an archive, completely independent of how compile works.

Comments

Sure (assuming you make the jar reproducible via strip-nondeterminism or similar).  As mentioned, I think the main concern is with AOT, which Debian does right now for clojure, leiningen, puppetdb, etc.  I believe that was done because startup was substantially slower otherwise.  And at the moment I'm just trying to understand what the current situation/options are before we start trying to decide what to do.

---

Similar questions are asked periodically by different people, roughly once a year. You're correct that compilation results are not repeatable, and it doesn't seem like something that will be changed any time soon, if ever.

Answer 2

Reproducible compilation is not currently a priority for us. But happy to leave this open to hear more reasons why that is important and collect votes.

Comments

OK, appreciate the answer.  Thanks.

---

One thing I noticed after a bit further investigation (and if I didn't misunderstand), it looks like it may not be possible to compile Clojure without a copy of previously compiled spec.alpha class files.  The spec.alpha .clj files are not sufficient.  I imagine that may well be intentional, but thought I'd mention it in case not, or in case I did misunderstand.

I noticed because I thought Debian might be able to keep Clojure by shifting .clj compilation to install time.  That did work fine for Clojure itself and Leiningen, two of the main cases where it would matter, but it looks like it won't work for clojure and spec.alpha if the conclusion above is correct.

Since clojure and spec.alpha appear to work when neither of them are compiled, Debian may be able to proceed that way, with of course much slower clojure, lein, etc. startup.
I'd thought maybe the clojure namespaces (from build.xml) could at least be compiled, but that provokes a crash if spec alpha isn't compiled. [edited after realizing that having both uncompiled does work]

---

Yes, you need to bootstrap Clojure 1.9+ using an existing version of Clojure, if you're compiling it.

I have to admit, I still don't really understand why distros/package manager folks insist on trying to do this with things that are essentially just libraries on Maven Central? You risk creating builds of Clojure that are not the same as what the vast majority of people just download from Maven as project dependencies.