Peter Simons
Now, the black-list approach has a significant advantage. In current versions of "cabal-install", it is possible for users to extend an incomplete black-list by adding appropriate "--constraint" flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way.
In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file.
...but on the down side w.r.t. to white-listing: doesn't the black-list approach allow for a clean-environment 'cabal install package-with-many-transitive-deps' to suddenly break because a new major version of a dependee package was uploaded to Hackage which causes disturbances in the "equilibrium" due to API incompatibilities (even though the PVP was followed)? On the other hand, the white-list approach ensures reproducible builds (again, assuming the PVP is followed) in the sense that if there was a valid install-plan yesterday with a given GHC version, cabal-install will be able to find one today as well with the same GHC even though Hackage may have received new major versions. In other words, the white-list approach strives to conserve the invariant of sound package version interdependency constraints. That invariant is usually not the weakest possible one, but it converges against the "ideal invariant". Whereas the black-list approach doesn't provide any such invariant, it's always lagging behind, trying to catch up with the "ideal invariant" as well, but from the other direction. So IMHO, from a formal standpoint, the white-list approach seems more "correct", as it doesn't ever lead to an incompatible set of packages being compiled/linked against each other. cheers, hvr