pkgs/top-level: use lib.systems.equals for crossSystem

[tie]

Description of changes

Fixes otherwise equivalent systems being treated as different by packages that compare stdenv.*Platforms using == operator.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[tie]

See also #237427

I think setting crossSystem just here in pkgs/top-level/default.nix to localSystem depending on the lib.system.equals result should preserve equality for buildPlatform and hostPlatform wrt localSystem and crossSystem across Nixpkgs since it is the main import entrypoint.

[roberth]

Looks like a good improvement.

Could you add a test? We have some in pkgs/test. Not sure about the best place. This might take a new kind of test that warrants its own file. pkgs/test/top-level/default.nix? You could write some assert expressions and end with a pkgs.emptyFile so that it's nix-build-able.

[tie]

@roberth, added tests, nix-build -A tests.top-level.

[Ericson2314]

This might be too pendantic, but I wonder if tests that instantiate all of Nixpkgs are more meta and therefore should be imported into pkgs/top-level/release.nix (perhaps not directly) rather than Nixpkgs itself.

(Basically the same issue I have with pkgsCross and friends.)

[roberth]

@Ericson2314 I kinda agree, but this is the pattern we have, and let's solve one problem at a time. Also pkgsCross seems worse, because at least many tests apply to any pkgs or use some of the same parameters.

@ofborg build tests.top-level

[github-actions]

Successfully created backport PR for release-23.05:

• [Backport release-23.05] pkgs/top-level: use lib.systems.equals for crossSystem #254920

[github-actions]

Git push to origin failed for release-23.05 with exitcode 1

[sternenseemann]

I don't get this change. If crossSystem is passed, we should cross compile always. It makes it even weirder that you can have native cross, but just if the platform set is different in a way you'd ordinarily wouldn't even consider a different platform (pkgsLLVM, pkgsStatic).

I also thought we had the long term goal of making native compilation being the same as cross compilation, i.e. always cross compiling. If we can't even trigger the “native cross” code path anymore due to this check, it's sort of hard to do any work towards it or play around with it.

[roberth]

IIRC the problem solved here was that this code relied on a rather unpredictable equality check, making the invocation of Nixpkgs very delicate when it comes to the exact identity (or value address if you will) of the values that are passed in for local and cross. This is basically never a thing in a language that's mostly referentially transparent under its own == operator.
More concretely, users implicitly and reasonably expect that the following produce the same package set:

• nixpkgs { cross = elaborate "a"; local = elaborate "a"; }
• let a = elaborate "a"; in nixpkgs { cross = a; local = a; }.

I'm sorry that this change broke your workflow, but I think this is still the right behavior, and we should solve the problem you describe explicitly.

I agree that unifying the native and cross code paths should be a goal (with the possible exception of splicing being slower than no splicing), so until we have achieved that it should definitely be possible to experiment with that code path.
You could work around it by making the platform object subtly different, but perhaps a better way is to add a Nixpkgs config option that enables the "native cross" code path instead of the "non-cross" code path.
Would that solve the problem for you?