Some collections of TeX Live contain packages which require Java on runtime, and pulls in JDK as dependency. I wonder whether JRE suffices for them, and how the JDK can be swapped out with JRE (for testing or for production).
The motivation is that I don’t develop in Java and would like to not have to download JDK updates every other week.
Edit: It seems that either I can create a overlay with JDK replaced globally, and evaluate texlive from that copy of nixpkgs, or have a copy of nixpkgs with the relevant script edited locally, and build from that. Perhaps there is an easier way.
I went back and read more of the source code surrounding Java.
It seems that the moment is that nixpkgs doesn’t provide a standard “JRE”.
Instead packages are given the opportunity to provide tailored versions of JREs, e.g.
A quick code search shows that very few packages take this approach. I suspect that a wide adoption of such would result in many copies of minimal JREs with minor differences, defeating the purpose completely, which is to reduce closure size.
In any case, to adopt this approach for TeX Live would in a sense be equivalent to providing a standard non-JDK-JRE.
Beyond what was said about how to potentially do it, please be aware that replacing the jdk/jre used within TL, might result in rebuild times higher than the time it takes to download the original JDK.
This doesn’t address the titular question, but in case someone doesn’t actually need the extremely dependent packages and is too lazy to pick the collections apart, here’s how they can exclude certain packages from a collection:
texliveBasic.withPackages ( # THIS PACKAGE EXCLUDES albatross FROM THE COLLECTION
ps: with pkgs; [ # other stuff
(collection-fontutils // {
tlDeps = collection-fontutils.tlDeps
|> builtins.filter (e : e.pname != "albatross"); # Albatross draws in JDK
})
]
)
Explanation: When assembling the texlive package using texlive.withPackages, the package selector receives a set of fake derivations (produced by buildTeXLivePackage from tlpdb.nix). For collections, the fake derivation is structually similar to texlivePackages.collection-*.passthru, whose attribute tlDeps is used to determine the dependencies. Manipulating their content affects the result derivation.
Remark 1: The fake derivation for packages with content is an actual derivation/attribute set. It may be possible to manipulate them to arbitrarily swap out dependencies.
Remark 2: As the packages under texlivePackages.* are merely placeholders for Hydra and not involved in the building process of the derivation, the following overlay does not achieve the intended behavior.