Hi, folks - I'm sure we are all familiar with the phrase "cabal dependency hell" at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): When publishing a Cabal package, you should ensure that your dependencies
in the build-depends field are accurate. This means specifying not only lower bounds, *but also upper bounds* on every dependency.
I understand that the intention behind requiring tight upper bounds was good, but in practice this has worked out terribly, leading to depsolver failures that prevent a package from being installed, when everything goes smoothly with the upper bounds relaxed. The default response has been for a flurry of small updates to packages in which the upper bounds are loosened, thus guaranteeing that the problem will recur in a year or less. This is neither sensible, fun, nor sustainable. In practice, when an author bumps a version of a depended-upon package, the changes are almost always either benign, or will lead to compilation failure in the depending-upon package. A benign change will obviously have no visible effect, while a compilation failure is actually *better* than a depsolver failure, because it's more informative. This leaves the nasty-but-in-my-experience-rare case of runtime failures caused by semantic changes. In these instances, a downstream package should *reactively* add an upper bound once a problem is discovered. I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified *only when there is a known problem with a new version* of a depended-upon package.