java-packages.nix: detect i686 using stdenv.hostPlatform#179648
Conversation
chisui
approved these changes
Jul 27, 2022
Author
|
Ping... |
`java-packages.nix` attempts to automatically decide which java to use for bootstrapping. When this works, it works well. However when it fails due to the user setting `config.allowNonSource=false` on a non-x86 platform, the reported failure is extremely confusing and does not mention the `NIXPKGS_ALLOW_NONSOURCE=1` option to proceed, or that `allowNonSource` had anything to do with the eval failure. Here's why this is happening: Currently, `java-packages.nix` makes its detection choice based on `adoptopenjdk.jdk-hotspot.meta.available`. If the user has set `config.allowNonSource=false` then the `adoptopenjdk-bin` packages will all report `_.meta.available==false`. If `adoptopenjdk.jdk-hotspot.meta.available==false` then the detection code will proceed to use `callPackage path args`, *even if that package is **also** `meta.unavailable`* for end-user-unfixable reasons. In the case of `openjdk8`, the `path` passed is a `nix` expression that only works on x86. The user has two options for continuing the build: buy an x86 machine or add an `allowNonSource` exception for the bootstrap jdk. The second option is generally preferred, but the user is only offered the first option. The following comment appears above the line in `java-packages.nix` which does the automatic selection: ``` /* adoptopenjdk not available for i686, so fall back to our old builds for bootstrapping */ ``` Since the intent here was to decide based on "i686-ness", let's query the authoritative source for i686ness in nixpkgs: `stdenv.hostPlatform`.
Author
This was referenced Apr 20, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
java-packages.nixattempts to automatically decide which java to use for bootstrapping. When this works, it works well. However when it fails due to the user settingconfig.allowNonSource=falseon a non-x86 platform, the reported failure is extremely confusing and does not mention theNIXPKGS_ALLOW_NONSOURCE=1option to proceed, or thatallowNonSourcehad anything to do with the eval failure.Why the problem is happening
Currently,
java-packages.nixmakes its detection choice based onadoptopenjdk.jdk-hotspot.meta.available. If the user has setconfig.allowNonSource=falsethen theadoptopenjdk-binpackages will all report_.meta.available==false. Ifadoptopenjdk.jdk-hotspot.meta.available==falsethen the detection code will proceed to usecallPackage path args, even if that package is alsometa.unavailablefor end-user-unfixable reasons.In the case of
openjdk8, thepathpassed is anixexpression that only works on x86. The user has two options for continuing the build: buy an x86 machine or add anallowNonSourceexception for the bootstrap jdk. The second option is generally preferred, but the user is only offered the first option.The fix for the problem
The following comment appears above the line in
java-packages.nixwhich does the automatic selection:Since the intent here was to decide based on "i686-ness", let's query the authoritative source for i686ness in nixpkgs:
stdenv.hostPlatform.Things done
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)