Best approach for updateScript when there are multiple hashes

A recent update to the 86Box derivation has necessitated fetching a second Git repository that is versioned using the same tag as the first Git repository, which would only be pulled into the build conditionally. Unfortunately, this breaks nixpkgs-update:

_86Box 4.1 -> 4.1.1
attrpath: _86Box
Checking auto update branch...
No auto update branch exists
[version] generic version rewriter does not support multiple hashes
[rustCrateVersion] No cargoSha256 or cargoHash found
[golangModuleVersion] Not a buildGoModule package with vendorSha256 or vendorHash
[npmDepsVersion] No npmDepsHash
[updateScript] skipping because derivation has no updateScript
The diff was empty after rewrites.

I saw that some projects use nix-update-script, so I tried that too. Unfortunately, it seems like this only updates the first hash and not both hashes. (This happens even when using it with the _86Box-with-roms derivation that actually includes the other repository in the build.)

My next thought was that it’d be easier to just ditch the in-place updating and instead move the repository data into a separate Nix file that can be generated by a trivial updateScript. But, I’m not 100% sure if that’s the right way to go for this situation; I couldn’t find a very similar situation, and I also couldn’t find a whole lot of discussion or documentation that clarified things.

If the answer is “that is indeed the way to go” then I suppose at least this topic can serve as a searchable answer to the question.

I believe you are free to do the way you want, under the condition it does not look too unmanageable in the future.

It is possible to use the updateScript with a loop:

Or even sequence multiple update scripts with the experimental combinators:


After taking a look, I came to the conclusion that it’s most straight-forward to just make a script that generates the sources data. There’s definitely some interesting techniques that could be applied that might work, and I can see the value in avoiding more one-off scripts for maintainability, but I suspect that for the time being, it’s just a bit easier to go with the one-off script, since it is fairly trivial.

I appreciate the input.