Enable config.strictDepsByDefault = true by default

[trofi]

strictDeps helps keeping cleaner PATHs for cross-compiled packages. But it's also useful to have for native builds: it helps writing nix derivations that have better chance of working when cross-compiled later.

A bunch of packages will need to sort out their buildInputs / nativeBuildInputs depends. Or more precise depsBuildBuild & co. finer grained equivalents.

nixpkgs/pkgs/stdenv/generic/make-derivation.nix

Lines 127 to 128 in cd88f86

	, # TODO(@Ericson2314): Make always true and remove
	strictDeps ? if config.strictDepsByDefault then true else stdenv.hostPlatform != stdenv.buildPlatform

[trofi]

Piling on the packages known to break with config.strictDepsByDefault = true:

• autoconf264: autoconf264: fix depends for strictDeps = true #178484
• automake111x: automake111x: fix depends for strictDeps = true #178499
• gumbo: gumbo: fix depends for strictDeps = true #178496
• hivex:
• kmod:
• libotr:
• librdf_raptor2:
• moreutils: moreutils: fix depends for strictDeps = true #178472
• tradcpp: tradcpp: move autoconf to nativeBuildInputs #178467

[erdnaxe]

libxml2 seems to break with config.strictDepsByDefault = true. Adding python in nativeBuildInputs fixes the issue.
I am not really confident to propose this as a patch as I don't understand why this exists: pythonSupport ? enableShared && stdenv.buildPlatform == stdenv.hostPlatform (in pkgs/development/libraries/libxml2/default.nix).

[Artturin]

libxml2 seems to break with config.strictDepsByDefault = true. Adding python in nativeBuildInputs fixes the issue. I am not really confident to propose this as a patch as I don't understand why this exists: pythonSupport ? enableShared && stdenv.buildPlatform == stdenv.hostPlatform (in pkgs/development/libraries/libxml2/default.nix).

python is probably being disabled because cross-compilation enables strictDeps and so breaks the python detection

i'll fix it

[erdnaxe]

There seems to be a similar issue to libxml2 with libxslt.

I am building a aarch64-linux NixOS system from master using config.strictDepsByDefault = true. I will update the following list with the files in which I had to add strictDeps = false; to get a working system:

• nixos/lib/make-options-doc/default.nix (in optionsJSON): libxml2: enable strictDeps and enable pythonSupport when cross #194941
• pkgs/development/libraries/libxml2/default.nix: libxml2: enable strictDeps and enable pythonSupport when cross #194941
• pkgs/development/libraries/libxslt/default.nix: libxml2: enable strictDeps and enable pythonSupport when cross #194941
• pkgs/development/perl-modules/Po4a/default.nix: perlPackages.{Po4a,AlienLibxml2},kmod,liblouis: enable strictDeps #218503
• pkgs/os-specific/linux/kmod/default.nix: perlPackages.{Po4a,AlienLibxml2},kmod,liblouis: enable strictDeps #218503
• pkgs/development/libraries/liblouis/default.nix: perlPackages.{Po4a,AlienLibxml2},kmod,liblouis: enable strictDeps #218503
• pkgs/top-level/perl-packages.nix: Alien-Libxml2 and XML-LibXSLT: libxml2: enable strictDeps and enable pythonSupport when cross #194941
• pkgs/tools/networking/openssh/common.nix: openssh: enable strictDeps #219308
• pkgs/tools/typesetting/tex/texlive/combine.nix (FORCE_SOURCE_DATE=1 fmtutil --sys --all is problematic)
• pkgs/tools/bluetooth/obex-data-server/default.nix: obex-data-server: enable strictDeps #219416
• pkgs/tools/bluetooth/blueman/default.nix
• pkgs/tools/misc/system-config-printer/default.nix
• pkgs/misc/drivers/gutenprint/default.nix: gutenprint: enable strictDeps #219309
• pkgs/misc/cups/filters.nix
• pkgs/development/libraries/libcbor/default.nix: libcbor: enable strictDeps #223705
• pkgs/development/libraries/openldap/default.nix
• pkgs/development/libraries/tracker/default.nix: tracker: enable strictDeps #219418
• pkgs/development/libraries/gjs/default.nix
• pkgs/development/libraries/qt-5/modules/qtbase.nix
• pkgs/development/libraries/qt-5/modules/qtwayland.nix
• pkgs/desktops/gnome-2/platform/gnome-vfs/default.nix
• haskellPackages.safe-exceptions ghc-9.6.5: could not execute: hspec-discover: haskellPackages.safe-exceptions: fix strictDeps build #322008

[Artturin]

libxml2, libxslt, optionsJSON: #194941

[Artturin]

perlPackages.{Po4a,AlienLibxml2},kmod,liblouis #218503

[AndersonTorres]

Ward because I need to learn this.

[infinisil]

Since nobody mentioned this before, we should only do this for Nixpkgs, not third-parties, at least not without a proper warning first. Otherwise we break package builds for thousands of users.

[trofi]

What are third parties exactly? Are (for example) users of .override, .overrideAttrs and overlays = [] considered to be third-parties? I wonder if nixpkgs even provides a way to distinguish internal from external users.

I had an impression that external users are expected to pin to a particular revision of nixpkgs to get a reasonable build result. Otherwise users have to constantly adapt to internal changes like gcc updates, parameter additions and removals, package removal/deprecation and .nix file moves. Largest breakages are usually covered by release notes.

[infinisil]

Overlays make this a bit tricky because it's how Nixpkgs defines its packages internally, but third-parties can also provide overlays. So I think it's fine to treat overlays as Nixpkgs code.

But other than that, anything using the resulting import <nixpkgs> {} value instead of going through overlays should be considered third-party code. And it's possible to implement code that can distinguish that (it'll have to touch the core of Nixpkgs though).

Notably this would also be useful for a number of other improvements to stdenv.mkDerivation that would be backwards-incompatible, but can happen in Nixpkgs.

I had an impression that external users are expected to pin to a particular revision of nixpkgs to get a reasonable build result. Otherwise users have to constantly adapt to internal changes like gcc updates, parameter additions and removals, package removal/deprecation and .nix file moves. Largest breakages are usually covered by release notes.

While we don't yet have a clear guideline on API stability guarantees, my take on it is that we should guarantee stability for the code that we control. This includes all the Nix code in Nixpkgs, including e.g. the passthru attributes of packages. We are responsible for that code and should take care to not break it.

But this doesn't include the contents of the packages: If upstream of a package happens to break for all users, we aren't responsible for that, it's upstream that should get the complaints. We can still include a note on that in the release notes as a courtesy, but it's not required.