Broken Haskell packages should be annotated why they are broken

Right now all the broken Haskell packages are treated equally and this makes unbreaking them really tedious. If an upstream package dependended by many packages breaks then those packages will also be listed as broken and needs to be manually unbroken. If we can annotate why they were marked broken then the build machine can try to unbreak packages held by one package automatically when that package is being fixed.
One downside I can think of is that this will add more load on to the build machine.

1 Like

I think this sounds like a good idea!

Although keep in mind that this is a non-trivial problem. It gets complicated when multiple (transitive) dependencies of a package keep going from broken to unbroken.


As a first step, I’d recommend creating a bot similar to r-ryantm that intelligently tries to recompile broken Haskell packages. When it finds one that is incorrectly marked broken, it could automatically send a PR to nixpkgs marking it as non-broken.

If we find out that this workflow works well (and has few false positives), then we could strongly consider merging it into the existing CI tools.


I’d also recommend taking a look at the static-haskell-nix project, which successfully got enough donations to sponsor a nice build machine.

2 Likes

Even just a comment saying why would help, I think, it turns it from “try and see, maybe it’ll work” to “ah, I see the reason still hasn’t been fixed, I don’t need to try”

1 Like

I’m not super familiar with it, but I think the stackage maintainers do something similar with the packages in stackage.

Although in practice I’ve found those types of comments to be really hit-and-miss in helpfulness.


These are the possible outcomes of building a haskell package on Hackage Matrix Builder.