On 6/23/10 10:06 PM, Duncan Coutts wrote:
Suppose both the zlib and tar packages specify "build-depends: bytestring-0.9.*". It's entirely possible for me to install zlib, then upgrade to a new bugfix release of bytestring, install tar (using the new bytestring) and then build htar depending on tar+zlib. In this case none of the developers of these packages have done anything wrong. It is situations like this that cabal-install tries to avoid.
Oh! Now I see. The impression that is coming to me now is that the package system is incredibly brittle, and so is very easy to break things even when theoretically following all of the rules. This isn't meant as a critique of the people who designed this system, mind you; it's works very well in practice for most things, and it is hard to see how these problems can be fixed without breaking other things.
So I propose the following question to the floor: are there any ideas for changing the package system to make it less brittle?
I think what you mean is that cabal-install should infer from the situation where package A needs 'C< 2' and package B needs 'C>= 2' that it is safe for a package to depend on both A and B and to be built indirectly depending on two versions of C. The fact that people can and often do make packages that work with either C 1 or 2 makes this situation less common. Also, it's not necessarily true, perhaps all it means is that the latest version of B now needs a later C and so my package now cannot use that later version of C because it did indeed pass values of types defined in C between functions defined in A and B (that is, my package has been busted by the latest release of B).
Okay, I see now why it's harder then I had figured it would be. Thank you for taking the time to explain to me why I was wrong. :-)
Cheers, Greg _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
