On Wed, 2010-06-23 at 21:05 -0400, Gregory Crosswhite wrote:
On 6/23/10 8:06 PM, Duncan Coutts wrote:
Consider an example where we want to avoid using two versions of a dependency:
The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other.
Okay, I hadn't considered this, though it seems like the real problem in this situation is that someone violated the package version policy: if tar is upgraded to use a newer, incompatible version of bytestring, then it should have an appropriate version bump that causes htar to ignore the new version and use the older version instead.
It's nothing to do with a version policy. Letting people opt-in and then enforcing a package versioning policy would be great, but it is orthogonal to this problem. 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. You could construct similar examples involving major versions rather than bugfix versions. All you need is for someone to have tested with two major versions and to mark their package as being able to work with either. 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). Duncan