Set strictDeps=true on our top level packages #192

Open

abonerib wants to merge 12 commits from enableStrictDeps into master

pull from: enableStrictDeps

merge into: rarias:master

rarias:master

rarias:fox-regression

rarias:pkgs/tacuda

rarias:pkgs/tasycl

rarias:robust-fetchGit

rarias:old-master

rarias:gitea-lfs

rarias:only-restart-logins

rarias:monitor-gpfs-home

rarias:add-tent-machine

rarias:m/raccoon

rarias:add-fpga-u280

rarias:maintenance-purchase

rarias:add-fox-machine

rarias:share-files

rarias:shared-nix-store

rarias:intro-nix

rarias:lake2-ipoib

Conversation 4 Commits 12 Files Changed 33 +303 -47

abonerib commented 2025-10-07 16:45:31 +02:00

Collaborator

Copy Link

rarias/bscpkgs#12

https://jungle.bsc.es/git/rarias/bscpkgs/pulls/12

abonerib changed title from WIP: Set strictDeps=true on our top level packages to Set strictDeps=true on our top level packages 2025-10-08 12:33:00 +02:00

rarias commented 2025-10-09 12:23:41 +02:00

Owner

Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

abonerib commented 2025-10-09 13:08:58 +02:00

Author

Collaborator

Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

We already discussed it bscpkgs: rarias/bscpkgs#10 (comment)

TL;DR: I think it's preferable to enforce strictDeps so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.

> I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve? We already discussed it bscpkgs: https://jungle.bsc.es/git/rarias/bscpkgs/pulls/10#issuecomment-4209 TL;DR: I think it's preferable to enforce `strictDeps` so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.

rarias commented 2025-10-09 13:38:54 +02:00

Owner

Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

We already discussed it bscpkgs: rarias/bscpkgs#10 (comment)

TL;DR: I think it's preferable to enforce strictDeps so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.

I have two issues with strictDeps:

1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future).
2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations.

If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.

> > I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve? > > We already discussed it bscpkgs: https://jungle.bsc.es/git/rarias/bscpkgs/pulls/10#issuecomment-4209 > > > TL;DR: I think it's preferable to enforce `strictDeps` so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand. I have two issues with strictDeps: 1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future). 2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations. If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.

abonerib commented 2025-10-09 14:54:55 +02:00

Author

Collaborator

Copy Link

1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future).

I have taken a look in stdenv and there the two takeaways are:

• When cross-compiling, by default it is enabled: f00b180ed4/pkgs/stdenv/generic/make-derivation.nix (L225)
  • This has the unfortunate consequence that setting strictDeps = false will affect cross compilation (I may be wrong)
• The actual logic is in the stdenv setup.sh: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L850
  • There are only 3 uses of strictDeps. From what I could understand:
    • 2 of them related to skip adding things to the HOST_PATH and
    • the other skips running setup hooks from activated packages. The setup hooks could do anything, so who knows what the consequences are.

2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations.

I think that explicitly setting it to false could also have unintended consequences (see above).

If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.

I agree that adding it by default magically to all our packages is a bit of a hack. Maybe we can add it as a ci target, but that would mean a lot of rebuilds.

> 1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future). I have taken a look in stdenv and there the two takeaways are: - When cross-compiling, by default it is enabled: https://github.com/NixOS/nixpkgs/blob/f00b180ed496b11337983fe4b0b979419cb3e472/pkgs/stdenv/generic/make-derivation.nix#L225 - This has the unfortunate consequence that setting `strictDeps = false` will affect cross compilation (I may be wrong) - The actual logic is in the stdenv setup.sh: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L850 - There are only 3 uses of strictDeps. From what I could understand: - 2 of them related to skip adding things to the HOST_PATH and - the other skips running setup hooks from activated packages. The setup hooks could do anything, so who knows what the consequences are. > 2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations. I think that explicitly setting it to false could also have unintended consequences (see above). > If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set. I agree that adding it by default magically to all our packages is a bit of a hack. Maybe we can add it as a ci target, but that would mean a lot of rebuilds.

abonerib changed target branch from master to upgrade/25.11 2025-12-09 15:17:40 +01:00

rarias changed target branch from upgrade/25.11 to master 2026-01-20 13:51:32 +01:00

rarias added 15 commits 2026-01-20 13:51:32 +01:00

Upgrade nixpkgs to 25.11 6e089344da

Fix renamed llvm bintools ... d2025d35d9

Moved from llvmPackages_latest.tools.bintools to
llvmPackages_latest.bintools

Set pyproject=true in buildPythonApplication ... eb9358abab

The buildPythonPackage and buildPythonApplication functions now
  require an explicit format attribute. Previously the default format
  used setuptools and called setup.py from the source tree, which is
  deprecated. The modern alternative is to configure pyproject = true
  with build-system = [ setuptools ].

Fix changed cudaPackages.cuda_cudart output ... 5bc928c407

See: https://github.com/NixOS/nixpkgs/pull/437723

Replace wrapGAppsHook with wrapGAppsHook3 ad812ea32d

Fix renamed option watchdog.runtimeTime ... 1457d85f4c

The option 'systemd.watchdog.runtimeTime' has been renamed to
'systemd.settings.Manager.RuntimeWatchdogSec'.

Use standard gcc for intel packages ... 209f8a582e

This reverts 26f52aa27d

Fix replaced nixseparatedebuginfod ... 2264e15102

nixseparatedebuginfod has been replaced by nixseparatedebuginfod2

Fix moved package linuxPackages.perf is now perf 87bf095dae

Mark mcxx as broken and remove from package list 1d3bda33a0

Set strictDeps to true on all our packages 21d9e132aa

Fix cudainfo buildInputs aab17ab0c4

Fix papi_version_check ... f77a36ee4c

Instead of running the papi_version binary, use the
builtin version check from pkg-config.

Remove unused sys-devices requirement in ld test b831f0a0bf

Fix openmp buildInputs 755e6dd1a7

abonerib force-pushed enableStrictDeps from 755e6dd1a7 to 1cb632a170 2026-01-21 12:43:58 +01:00 Compare

abonerib force-pushed enableStrictDeps from 1cb632a170 to 61ed93c951 2026-01-21 12:46:25 +01:00 Compare

abonerib added 1 commit 2026-01-21 15:11:49 +01:00

Do not force derviation inputs, use booleans instead fb653b7d98

abonerib force-pushed enableStrictDeps from fb653b7d98 to 0ac3d3e515 2026-01-21 15:13:36 +01:00 Compare

abonerib force-pushed enableStrictDeps from 0ac3d3e515 to 9c6f2e0097 2026-01-21 15:16:10 +01:00 Compare

Some checks failed

Hide all checks

CI / build:cross (pull_request) Successful in 8s

Details

CI / build:all (pull_request) Failing after 35m38s

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin enableStrictDeps:enableStrictDeps

git checkout enableStrictDeps

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

ceph

ci

config

cross

hw

io

kernel

mpi

net

nix

ops

repair

slurm

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

abonerib arocanon varcila rarias

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rarias/jungle#192