[Haskell-cafe] Rewriting a famous library and using the same
name: pros and cons
gcross at phys.washington.edu
Thu Jun 24 16:08:23 EDT 2010
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. :-)
More information about the Haskell-Cafe