Changing requiredSystemFeatures changes hash

[timor]

(Originally filed here: https://github.com/NixOS/nixpkgs/issues/57649)

In our setup, a hydra instance provides pre-built packages for all our necessary NixOS configuration, CI, etc...

We encountered a problem when we needed finer control over which build host gets assigned certain build steps. Specifically rustc was repeatedly assigned to a machine that could not handle it. (big-parallel had not been added to rustc on that nixpkgs channel). To work around that, we changed the requiredSystemFeatures attribute in an overlay, to make sure the build does not fail because of resource restrictions.

Unfortunately, this changes the hash of the derivation, and thus all downstream dependencies. This means that the official binary cache cannot serve these packages anymore, as only our local binary cache produces them, although nothing in the final artifacts is different from the original package(s).

As far as I can tell, requiredSystemFeatures should not have any influence on the artifact itself, only on the way it is built. If that is the case, would it be feasible to have it not influence the resulting hash?

If not, is there any other way to influence per-package hydra behavior?

Possibly related: https://github.com/NixOS/nixpkgs/issues/16263

[edolstra]

Indeed Nix currently has no way to have derivation attributes that are ignored for the purpose of computing output store paths. This wouldn't be very hard to add, but it would require changing the .drv format and Derivation data type to add "out of band" information.

[grahamc]

This is especially complicated since both behaviors are feasibly desirable. To make it concrete, I have cases where I do want a change in the required system features to cause a rebuild. For example having the same base derivation but built on a variety of different hw, selected by required system features.

[timor]

... I do want a change in the required system features to cause a rebuild.

Maybe it makes sense to look at "cause a rebuild" and "change hash" as distinct concepts (obviously the latter will always cause the former, but not necessarily the other way round)?

[7c6f434c]

@grahamc to be honest, if you already override required features, also setting an ignored variable is a straightforward trick; working around the defaults in the opposite direction is harder.

[FRidh]

For example having the same base derivation but built on a variety of different hw, selected by required system features.

I think in that case the hardware would need to be specified twice:

1. in the actual derivation so it knows what to build for (see also https://github.com/NixOS/nixpkgs/pull/59148)
2. requiredSystemFeatures to actually find a candidate machine to perform the build.

I see no valid reason for requiredSystemFeatures having to impact the hash.

[timor]

2. `requiredSystemFeatures` to actually find a candidate machine to perform the build.

Maybe this could be something which can also be controlled/overridden conveniently by a hydra-evaluator at evaluation time? This way, one could also steer build machine association without having to touch nixpkgs.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[stale[bot]]

I closed this issue due to inactivity. → More info

[SuperSandro2000]

We cannot somehow workaround this by moving big-parallel to meta?

[Ericson2314]

@SuperSandro2000 that would stop it from going to the store layer entirely.

To implement this, I would use 'ParsedDerivation` to indicate an opt-in that the required system features should be ignored for output hashing purposes.

[Ericson2314]

to be honest, if you already override required features, also setting an ignored variable is a straightforward trick; working around the defaults in the opposite direction is harder.

Yeah I think that is the easiest way to handle the "rebuild desired" use-case.