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

[Eelco Dolstra]

Hi,

Currently, of the 28971 jobs in the Nixpkgs jobset, 20573 are builds of Haskell
packages.  This is primarily the result of each Haskell package being built with
several GHC versions, sometimes with or without profiling:

>   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.

What do you think?

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/