Peter Simons <sim...@cryp.to> wrote: > Hi Tobias, > > > A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified) > > B 2.5.3.0 build-depends: C ==3.* (underspecified) > > C 3.7.1.0 > > > > Everything works nice until C-3.8.0.0 appears with incompatible changes > > that break B, but not A. > > > > Now both A and B have to update their dependencies and we have now: > > > > A 1.1.5.0 build-depends: B ==2.5.* C >=3.7 && <3.9 > > B 2.5.4.0 build-depends: C >=3 && <3.8 > > C 3.8.0.0 > > > > And now the following combination is still valid: > > A 1.1.5.0 > > B 2.5.3.0 (old version) > > C 3.8.0.0 > > Bang! > > thank you for contributing this insightful example. > > When such a situation has arisen in the past, it's my experience that the > author of B typically releases an update to fix the issue with the latest > version of C: > > B 2.5.4.0 build-depends: C >= 3.8 > > So that particular conflict does hardly ever occur in practice.
And what if the maintainer of a takes the chance to make some major updates and directly releases 2.6? Then all packages depending on 2.5.* will probably break. > Note that package A would build just fine after that update of B -- if the > author of A hadn't overspecified its dependencies. As it is, however, a > new version of A has to released that changes no code, but only the Cabal > file. But all this boils down to a system where only a combination of latest versions will be stable. So why restrict dependencies anyway? Tobi _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe