I definitely agree! http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/
L. On Wed, Aug 15, 2012 at 12:38:33PM -0700, Bryan O'Sullivan wrote: > 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. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Lorenzo Bolla http://lbolla.info _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
