 | NixOS JVM | 110 Members |
| 24 Servers |
| NixOS JVM | 110 Members |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Mar 2025 | ||
 msgilligan | Well, yeah actually maintaining the JDK is a lot of work. But other vendors can do it and I think some of the big ones do for paid support. | 03:28:24 |
 emily | because you can look at the stream of advisories and see that it's really like clockwork. it just comes down to gambling in the end | 03:28:43 |
| emily | we don't like to gamble with users' security | 03:29:02 |
| msgilligan | I'd move really fast to the new one. But having releases deleted automatically, in the same PR as the new release seem excessive. | 03:29:14 |
| msgilligan | Well, I'm talking about availability on unstable. And saying that marking them as knownVulnerabilities immediately even if there aren't any. | 03:30:24 |
| msgilligan | I'd say users of NixOS who are not paying anything and using non-LTS releases on the unstable branch that are out of upstream support are gambling with their own security. And personally, I'm willing to do that because my main use case is developing alpha software that will eventually run on the stable branch. | 03:31:59 |
| emily | tbh I don't really think of it as deleting. just as an update. there's the LTS releases and a rolling stream of the latest one | 03:32:21 |
| emily | knowmVulnerabilities would be adequate but it does mean that you will have to compile it yourself | 03:32:58 |
| emily | and that takes a rather long time | 03:32:59 |
| emily | BTW we do keep binary JDKs around and marked EOL | 03:33:10 |
| emily | because those don't impose any meaningful maintenance burden and also have no compile cycle | 03:33:33 |
| emily | so Temurin is an option | 03:33:48 |
| msgilligan | I'm getting the feeling that "we don't like to gamble with users' security" is at least partly a rationalization for avoiding maintenance burden on the source (and if that's the case, it makes sense and have no problem with it) Because the Temurin 23 will have the same vulnerabilities as the OpenJDK 23 built from source. I'm not trying to be argumentative, I just want to understand what you feel the tradeoffs are. Because I totally get the maintenance overhead argument and completely respect it. For my use case, using binary JDKs is probably fine. (Though I would migrate to the one built from source when JDK 25 is released.) But that also means the interim releases as-built-by-Nixpkgs are getting less testing. | 03:41:57 |
| emily | the gambling was re knownVulnerabilities | 03:44:45 |
| emily | if we set it on both then no gambling | 03:44:56 |
| emily | but one of them takes hours to build and the other seconds | 03:45:05 |
| emily | so the UX is kinda better with the Temurin package once marked | 03:45:19 |
| emily | (and yeah a package that's just a download is very low maintenance) | 03:45:46 |
| msgilligan | But this unmerged PR looks (to my beginner's eye) like it removes Temurin 23 as well: https://github.com/NixOS/nixpkgs/pull/391811/files#diff-79588acae2eadf21386a83519365d48aad6c7162da39897f429bca64ad8437ff | 03:46:02 |
| emily | yeah, it does. I haven't reviewed the PR. I guess I should say "at some point we have done things like this" :) | 03:48:09 |
| emily | FWIW "drop source, mark binary" is how Electron maintainers handle EOLs | 03:48:32 |
| msgilligan | My project will survive no matter what the NixOS JVM team decides, but I really like Nix, want to provide feedback and help as I can, and use Nix as fully as possible in my build. I'm also eventually hoping to get some Java apps into nixpkgs. If the human and infrastructure resources are sufficient for keeping the built-from-source packages in | 03:54:17 |
| msgilligan | I also will try to learn various methods for testing PRs and pre-release branches as much as possible (and how to automate this on some of my systems, if possible) | 04:01:01 |
| msgilligan | If anyone has any pointers to good references on how to do this, it would be appreciated. Especially anything that is Java or Rust focused (I also have some Rust projects I am trying to Nix-ify) I guess I could try to configure GitHub and/or GitLab to pull from release branches, for example. And maybe automatically do | 04:06:22 |
| msgilligan | * If anyone has any pointers to good references on how to do this, it would be appreciated. Especially anything that is Java or Rust focused (I also have some Rust projects I am trying to Nix-ify) I guess I could try to configure GitHub and/or GitLab to pull from release branches, for example. And maybe automatically do | 04:06:57 |
 Tomodachi94 (they/them) | (I'd be willing to vouch for you if you want to be put onto the Java team; I'm probably not the only one who thinks you'd make a great addition) | 04:20:14 |
| Tomodachi94 (they/them) | * (I'd be willing to vouch for you if you want to be put onto the Java team so you get pings for this kind of stuff; I'm probably not the only one who thinks you'd make a great addition) | 04:20:26 |
| Tomodachi94 (they/them) | On the testing PRs bit, our CONTRIBUTING.md is quite good nowadays: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:26:46 |
| Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:01 |
| Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted (id that the right word?) to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:26 |