[Nix-dev] Reducing the number of Haskell builds in the NixOS/Nixpkgs channel

[Andres Loeh]

Hi.

>>   haskellPackages_ghc6104             = recurseIntoAttrs (haskell.packages_ghc6104);
>>   haskellPackages_ghc6123             = recurseIntoAttrs (haskell.packages_ghc6123);
>>   haskellPackages_ghc704              = recurseIntoAttrs (haskell.packages_ghc704);
>>   haskellPackages_ghc741              = recurseIntoAttrs (haskell.packages_ghc741);
>>   haskellPackages_ghc742_no_profiling = recurseIntoAttrs (haskell.packages_ghc741.noProfiling);
>>   haskellPackages_ghc742_profiling    = recurseIntoAttrs (haskell.packages_ghc741.profiling);
>>   haskellPackages_ghc742              = recurseIntoAttrs (haskell.packages_ghc742.highPrio);
>>   haskellPackages_ghc761              = recurseIntoAttrs (haskell.packages_ghc761);
>>   haskellPackages_ghc762              = recurseIntoAttrs (haskell.packages_ghc762);
>
> This number of builds is not really a problem for Hydra, but it is for the
> binary channel generation: the NixOS and Nixpkgs channels are only updated after
> *every* package in the latest jobset evaluation has been built and mirrored.  So
> having 71% of the channel consist of Haskell packages adds considerable latency.
>
> I would suggest removing most of the GHC versions from the channels (i.e. remove
> "recurseIntoAttrs"), except the default (7.4.2) and the latest (7.6.2).  If
> desired, we could create a separate Hydra jobset to build the other versions.

At the moment, this would be fine. I'm hardly using anything that's
older than 7.4.2 right now. There are phases in GHC development though
where having builds for three different versions is really helpful.

Creating a separate Hydra jobset might be a good option, but I have no
experience with how that's done.

Cheers,
  Andres