| 18 Apr 2026 |
 samasaur | ah yeah not necessarily a config, my bad | 18:06:07 |
| samasaur | in that case you'll want to override the derivation that depends on openjdk to use the overridden one | 18:06:35 |
| samasaur | e.g.
hello.override {
openjdk = openjdk.override {
enableGtk = false;
};
}
| 18:07:01 |
| samasaur | the alternative to doing this on a case-by-case basis is to add an override to your instantiation of nixpkgs so that gtk is off for openjdk everywhere openjdk is used | 18:07:49 |
| samasaur | which has wider-ranging implications obviously but i think shoujld be fine in this case | 18:08:08 |
 Alice | we just, don't want nix to pull in dependencies which are not actually required | 18:08:23 |
| samasaur | is this flake public somewhere | 18:08:49 |
| Alice | (like, this flake we are making does not require gtk/graphics, but if some other thing on the system does, we don't want nix to pull openjdk and openjdk with disabled gtk | 18:09:48 |
| Alice | well, the flake itself is pretty small, so, here, | 18:11:29 |
| samasaur | well that's hard to do because the flake is pure and doesn't depend on the system | 18:11:28 |
| Alice | Download flake.nix | 18:11:29 |
| samasaur | there's no way for the flake to know whether the system already needs openjdk with GTK | 18:11:54 |
| Alice | well, we wouldn't think that that would be the job of the flake | 18:12:17 |
| Alice | but of the system, to see that flake says "i need a jdk, of openjdk variety, optionally with gtk" and go "yeah, we have openjdk, here you go" | 18:13:31 |
| samasaur | that's the kind of thing that nix explicitly tries to avoid, because doing that inevitably runs into obscure and hard to debug errors when the jdk provided by the system isn't compatible with the package for whatever reason | 18:14:59 |
| samasaur | the nix way to do what you're trying to do would be to have users of the flake override it to use a jdk that they know they're already using on their system | 18:16:43 |
 msgilligan | It seems like there could be some kind of preprocessing step that outputs a flake configuration that meets the requirement of a single JDK that satisfies dependencies of other packages. | 18:50:46 |
| samasaur | i mean you very well could define a flake output that needs to be passed a JDK | 18:51:16 |
| samasaur | it's just not the typical way things are done because then nix run, nix shell, etc. won't work | 18:51:48 |
| Alice | that's "true", but feels like, kind of a shit UX, tbqh | 18:52:09 |
| samasaur | you could also define it to optionally take a JDK and fall back to pkgs.openjdk if one isn't passed | 18:52:20 |
| samasaur | but there's an infinite number of cases like this where your dependencies are configured to build with dependencies of their own that you don't care about | 18:53:09 |
| samasaur | my recommendation would be not to bother, because a) normal gradle/openjdk will be cached on hydra and an overriden one will not; b) chances are users of your package will already have the normal (non overriden) openjdk in their nix store due to other packages; c) users who actually care about extracting every little bit of space can do the overriding themselves | 18:55:38 |
| samasaur | now if you are in a situation where you need to be this precise about dependencies due to disk usage, maybe you come to a different conclusion than i did | 18:56:53 |
| msgilligan | I wonder if something like this would help for these use-cases: https://www.socallinuxexpo.org/scale/22x/presentations/configurable-flakes | 19:04:59 |
| 19 Apr 2026 |
|  @rasmata:matrix.org joined the room. | 13:08:38 |
| @rasmata:matrix.org left the room. | 13:08:42 |
| 21 Apr 2026 |
 ortolanbunting3002 | Is there a good way to handle Linux binaries from dependencies managed via the gradle setup-hook? There are gradle plugins which download linux binaries, which don't work (Most likely because the ELF interpreter isn't set properly). Is there a way to make them work? I've thought of autoPatchelf, nix-ld or buildFHSEnv. But I'm not sure of how to integrate those with the build of a gradle application. | 07:32:16 |
 Benedikt Ritter (britter) | The short answer is: no
I've been running into the plugin when I tried to use the protobuf gradle plugin. It wraps protoc which it loads from maven central if I remember correctly. Or maybe it was a protoc plugin that was loaded separately from Maven Central.
Anyway, the issue with these things is that there's no unified way to point them to a directory for looking up natives. Some may have a system property, some may look at PATH, sometimes there's a Gradle plugin config...
So I wouldn't know how to solve this problem in a generic way.
I think what we would need is to be able to have drvs for all libs on maven central and then be able inject the build time dependencies on the nix level.
But thats a completely different and radical approach compared to the dependency FOD solution that we have right now.
| 08:17:19 |
| Benedikt Ritter (britter) | I solved my problem by putting everything into the env and using nix-ld. | 08:17:49 |
