[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Gregory Crosswhite]

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