On 08/08/2014 02:35 PM, Eelco Dolstra wrote: > Hi, > > On 08/08/14 12:39, Luca Bruno wrote: > >> I've launched this Zero Hydra Failures (ZHF) project. Details at >> https://nixos.org/wiki/Zero_Hydra_Failures > > Great, thanks! > > For reference, here is a list of nixpkgs:trunk jobs that have been broken for > at > least 6 months: > > http://nixos.org/~eelco/.bla/broken-6-months.txt > > and jobs that have never been built successfully (which may include new jobs): > > http://nixos.org/~eelco/.bla/broken-forever.txt > > These are candidates for not building on some platforms, being marked as > broken > or being removed. > > Note the huge number of Haskell and Python packages. >
The problem with Haskell jobs as far as I can tell is that we often remove old versions of packages when ‘updating’. Consider something like QuickCheck 1.x: we update its dependencies in nixpkgs and the package now becomes forever broken because we haven't kept the old version of things and told QC to use that. QC 1.x is old so it's not reasonable to go back and make it work with new dependencies: upstream won't do it and everyone will probably use QC 2.x. If there are packages depending on 1.x then they should be updated instead. As far as I can tell we need to do one of the following * Remove Haskell packages which don't build with what's in nixpkgs as long as a newer version exist. This is a problem if other packages depend on this specific version and the only way to fix that is to make those packages work with what's in nixpkgs or remove them too if they are not the most recent version. * Start preserving more package versions and start using specific package versions. The first solution seems preferable as it will remove the most broken packages in the tree. I would be interested to see some kind of statistics for how many attempted downloads there were for something like QC 1.x: is such a statistic available? This downside is that it's hard to tell what will break when we update a package unless we build everything that depends on it. I think it's fine to break it once as long as Hydra tells us and we can go back to fix it. It beats breaking it forever. The second solution would be a large added maintenance and Hydra burden as the number of packages would increase dramatically. In turn we would have binaries for a lot of versions which while nice, is probably a waste of resources: users very often want latest version. I think the first way is preferable (start removing things) but it's vital that there are clear instructions for * Adding own package versions: we often get questions in #nixos on what to do if a Haskell package is not in nixpkgs. With this we'll need clear instructions more than ever. So, define own Haskell package set with packageOverrides in config.nix… Perhaps a wiki page somewhere. * Instructions to the packagers on how to see what we're affecting when removing a package version. -- Mateusz K. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
