The per-version `default.nix`es just fill in default arguments. It is
much more useful to have the `.override` from the inner `callPackage`,
for finer control. Converting the outer `callPackage` to a plain import
makes the inner one the only one, revealing its `.override`.
/cc @Ericson2314
PR was https://github.com/NixOS/nixpkgs/pull/46857
This line broke MacOS cross compilation. paxctl cannot be built on
macOS. Maybe it can be fixed, but no reason to break things
unnecessarily.
Regardless, you definitely need to be more careful about backporting.
I think it’s fine to move fast and break things on master but
with release-18.09 we should be more careful. Something like more
automated testing for cross compilation would also be
helpful (hopefully even making it block).
(cherry picked from commit f9c4075873cb56464126f993d22a1a72f7cfac45)
The compilers themselves can pull them from `bootPkgs`, where they
should always come from anyways. This enforces that, simplifies that
code, and allows use to avoid more `rec { ... }` too.
The `overrideScope` bound by `makeScope` (via special `callPackage`)
took an override in the form `super: self { … }`. But this is
dangerously close to the `self: super { … }` form used by *everything*
else, even other definitions of `overrideScope`! Since that
implementation did not even share any code either until I changed it
recently in 3cf43547f4, this inconsistency
is almost certainly an oversight and not intentional.
Unfortunately, just as the inconstency is hard to debug if one just
assumes the conventional order, any sudden fix would break existing
overrides in the same hard-to-debug way. So instead of changing the
definition a new `overrideScope'` with the conventional order is added,
and old `overrideScope` deprecated with a warning saying to use
`overrideScope'` instead. That will hopefully get people to stop using
`overrideScope`, freeing our hand to change or remove it in the future.
This ensures that any further changes needing notes that belong in 18.09
off this common-ancestor commit can be easily merged to both
`release-18.0`9 and `master`.
There were many reverts back and forth, but it ultimately appears that I
am the source of this mistake. I clarified the comment so as not to
confuse myself or anyone else.
1. CHOST is how one specifies the cross host platform with this
non-standard configure script. We were just getting lucky with Linux
cross.
2. install_name_tool needs the the binutils prefix.
This isn't a MUSL thing, but just needed for cross compilation to x86.
No one had tried this when all cross compilation was to linux + glibc,
hence why no one noticed this until recently.
A little shim derivation to get this header for Darwin, where it is
needed for cross compilation.
There's no real reason to do glibc and musl like that, but as I'm
maintaining it I suppose I can go overboard like that.
Take two of #40708 (4fe2898608).
That PR attempted to bidirectionally default `config.nixpkgs.system` and
`config.nixpkgs.localSystem.system` to each be updated by the other. But
this is not possible with the way the module system works. Divergence in
certain cases in inevitable.
This PR is more conservative and just has `system` default `localSystem`
and `localSystem` make the final call as-is. This solves a number of
issues.
- `localSystem` completely overrides `system`, just like with nixpkgs
proper. There is no need to specify `localSystem.system` to clobber the
old system.
- `config.nixpkgs.localSystem` is exactly what is passed to nixpkgs. No
spooky steps.
- `config.nixpkgs.localSystem` is elaborated just as nixpkgs would so
that all attributes are available, not just the ones the user
specified.
The remaining issue is just that `config.nixpkgs.system` doesn't update
based on `config.nixpkgs.localSystem.system`. It should never be
referred to lest it is a bogus stale value because
`config.nixpkgs.localSystem` overwrites it.
Fixes#46320
