Having the current bash hash present in the nixpkgs tree makes Nix
detect bash as a runtime dependency of nixpkgs, which in turns messes up
`fetchFromGitHub` due to https://github.com/NixOS/nix/issues/6660
Because downstream code expects to use `==` on platform attrsets, we
are unfortunately not able to throw a useful error message when the
`sharedLibrary` attribute is accessed.
When users do a comparison like:
stdenv.hostPlatform == pkgsStatic.stdenv.hostPlatform
... in a situation where `stdenv.hostPlatform.hasSharedLibraries`,
they expect this to return `false`. Unfortunately Nix does a deep
equality comparison here, and ends up forcing the
`pkgsStatic.stdenv.hostPlatform.extensions.sharedLibrary` attribute,
which throws the error.
Rather than returning `null`, this commit instead simply omits the
`extensions.sharedLibrary` attribute. This provides the user with a
more-useful error message: instead of waiting until the `null` is
used (and hoping that produces an error), the user will get an error
about the `extensions.sharedLibrary` attribute being missing, at the
position where it was referenced.
Big thanks to @trofi for his PR to add
`NIX_VALIDATE_EVAL_NONDETERMINISM` to Nix, which I am now using. It
made tracking this down really easy!
Fixes#244045
This commit adds `hasSharedLibraries` to `lib.systems`.
We need `plat.hasSharedLibraries` in order to know whether or not to
expect `gcc` (and many other tools) to emit shared libraries (like
`libgcc_s.so`). Many of the GNU build scripts are smart enough that
if you configure them with `--enable-shared` on a platform (such as
`arm-none-eabi`) that doesn't support dynamic linking, they will
simply skip the shared libraries instead of aborting the
`configurePhase`. Unfortunately the missing shared libraries in the
final build product cause very hard-to-troubleshoot problems later
on.
The alternative to introducing `hasSharedLibraries` would be to set
`isStatic` in these situations. However doing so causes
`make-derivation.nix` to insert `-static` between the `pname` and
`hostPlatform` suffix, which is undesirable.
If at some point in the future we eliminate the `-static` suffix,
then `hasSharedLibraries` can be made equal to `!isStatic`.
often sections aren't needed when using globalSection
currently one has to `sections = { }` when using only globalSection
```
lib.generators.toINIWithGlobalSection { } {
globalSection = {
background_color = "1d202199";
};
sections = { };
};
````
* licenses: add opubl
* texlive: fix license for npp-for-context and lshort-german
This unbreaks evaluation for `texlive.combine { inherit (texlive) scheme-full;
pkgFilter = (_: true) }`. The problem doesn't manifest for the default pkgFilter
as `npp-for-context` is a doc-only-package (that by the way has recently been
removed from texlive).
toLosslessStringMaybe is not used by anything other than lib/tests,
so it can be private to that file.
I don't think this function was terribly well thought-through. If
people start using it, we will become permanently dependent on the
ability to test platforms for equality. It also makes the
elaboration process more fragile, because it encourages code outside
of nixpkgs to become sensitive to the minute details of how
elaboration happens.
The eminent Donald E. Knuth should be recognized as having equal
standing with such entities as IBM, Apple, and the Personal
Computer. We should acknowledge this by including him as a "vendor".
Also, `gnu-config` recognizes `mmix-knuth-*` triples (and in fact
requires `vendor="knuth"` when `cpu="mmix"`) -- so we sort of have
to. But we should do it anyways.
This will let us make assertions involving _module.args.pkgs, which
is not an option but a value attribute, and therefore doesn't have
its own highestPrio to inspect. The new function gives us that info.
with docbook gone and MD the default these aren't needed any more. we
can't remove them yet because there's thousands of uses, but maybe some
day we can.
no longer supported. warning when used would not be appropriate, and
docbook has been on the way out for long enough that throwing an error
should not be necessary either.
We already have examples for these, but since we didn't actually
recognise the doubles, it wasn't possible to build any packages for
them without setting allowUnsupportedSystem.
Previously it would fail with
error: attribute 'nonexistent' missing
at nixpkgs/lib/filesystem.nix:29:10:
28| if dirOf path == path then "directory"
29| else (readDir (dirOf path)).${baseNameOf path};
| ^
30|
Previously this function couldn't handle / being passed, it would throw
an error:
error: attribute '' missing
at nixpkgs/lib/filesystem.nix:24:20:
23| */
24| pathType = path: (readDir (dirOf path)).${baseNameOf path};
| ^
25|
Consequently this also fixes the
lib.filesystem.{pathIsDirectory,pathIsRegularFile} functions.
Although Lens is based on a free core component ("OpenLens"), the tarballs
provided by Mirantis include a proprietary version of Lens that requires
a subscription.
As the proprietary option offers additional features, it would not be wise
to simply rewrite the derivation and base it on the FOSS source code.
Instead, implementing a new derivation for OpenLens is likely the better
approach.
I imagine this was supposed to be rustc = args.rustc, like the other
two lines. This meant that we accepted both rust and rustc
attributes, with the same effect. I doubt anybody was using the
undocumented, probably-accidental "rust" spelling, but we should
remove it before somebody starts.
In fact, we don't need to set rustc here at all, because no value
platforms.select could return will ever include a rustc key (unlike
the other two), so then rustc will be filled in later, when args is
merged into final.
This is to avoid stealing keys from submodules. `class` might be
common enough that reinterpreting existing `class` attributes in
configurations as a declaration leads to fairly widespread problems.
This is appears to be a fairly common mistake for beginners who want
to build larger things from the system configurations, such as NixOps
networks, etc. Further explanation seems appropriate.
The supposedly public nature of these functions has been holding
back module system maintenance, while usages of these functions
are expected to be rare. If used anywhere, presumably they're
emulating module system behavior because some use case isn't supported
properly. We should try to support such a use case directly, if it
even exists.
Some options have their default value set in the `config` instead of
`default`, for example to push `mkDefault`s down an attribute set.
In those cases, it's useful to provide a `defaultText` for informational
purposes.
Previously, there was no way to unset an option when overriding a
kernel, apart from writing out the attrset yourself. Now it's
possible with lib.mkForce lib.kernel.unset. It's important to be able
to do this, because setting an option in the override may cause other
options to become unused, which would fail the config build unless
they were overridden too.
It makes sense to allow platform definitions to opt out of having libc
at all. One use case would be targetting some obscure new Linux
target that doesn't have a libc implementation yet, and another is
UEFI, which is basically libc-less Windows.
Not having libc is not commonly specified in (GNU) triples (even
Linux's build system will just target either -gnu or -musl depending
on the platform), so instead, we use a separate attribute for it.
