rPackages: eval and build

[jopejoe1]

Split from #434501

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Relevant discussion in #434501 (comment).

[jopejoe1]

Any feedback on this?

[wolfgangwalther]

I have asked in the Staging room on Matrix, but there is no clear feedback, yet.

[vcunat]

I'm honestly worried that adding almost 100k jobs permanently won't be cheap for the infra even if the jobs themselves are "cheap" (which I assume). Even nowadays for *-linux we're typically blocked on the central parts and aren't able to fully utilize the builders (sometimes aarch64-linux:big-parallel is an exception).

[vcunat]

Those permanents jobs would get rebuilt from scratch every week or two. So it's much much cheaper to do the separate jobset from time to time if the people around R desire that, especially if we do it on a single linux platform only.

[wolfgangwalther]

For future reference / decision making and understanding: The limiting factor here is evaluation? The queue runner? The actual builds?

Is there a certain factor that would need to change in the future, so that this becomes possible to do?

[vcunat]

Evaluation would be somewhat longer surely. I don't think that's a big issue itself, though what I see as limiting is that the whole eval happens inside a single postgresql transaction. Making it even more humongous certainly is a risk. Even now we can get several minutes of hydra almost stalling because of processing this transaction and other tasks like working on jobs from the same jobset would often conflict from DB point of view. (the biggest jobsets have something like 260k jobs now, so increase by 100k would be significant)

Overall I'd say the most limiting factor is ingestion of builds by the queue runner. No idea if that will be significantly better by some change soon, e.g. the runner rewrite or some cache.nixos.org changes.

[wolfgangwalther]

Cool, thanks for that helpful info!

Overall I'd say the most limiting factor is ingestion of builds by the queue runner. No idea if that will be significantly better by some change soon, e.g. the runner rewrite or some cache.nixos.org changes.

Will we be able to test / know once these are available - or would we have to test building rPackages in practice once that's the case?

[vcunat]

It seems hard to know exactly. Even measuring, as in normal hydra.nixos.org you tend to do multiple things at the same time.

[jbedo]

We're currently in a tough spot as rPackages is not built as part of trunk, and the r-updates jobset has been disabled since pre 24.11, leaving us with no CI at all. I've been running a hydra server on my own hardware for the past year so that we can still update the tree with some quality control. I'd be happy to collect any statistics on my hydra server that would help.

[vcunat]

r-updates on x86_64-linux once in a while is certainly no issue for hydra.nixos.org, with only a small fraction of price of this PR, I'd say.

[jopejoe1]

What I wanted to do with this PR gets done now with #482817