On Thu, 2008-10-09 at 09:16 -0700, Don Stewart wrote: > Main problem now, particular, network-2.2.0.0 is failing under cabal-install, > outside of the network tree, cabal-install assigns: > > Dependency base -any && ==4.0.0.0: using base-4.0.0.0 > Dependency parsec -any && ==2.1.0.1: using parsec-2.1.0.1 > > which will fail. But notably, inside the network source tree, > cabal-install does pick base-3. > > However, network-2.2.0.0 is also installed by the GHC release candidate, > with dependencies, > > depends: base-4.0.0.0 parsec-2.1.0.1 syb-0.1.0.0
For an hour this morning I could not for the life of me think what might cause this. Then I remembered that I'd added even more cleverness into the resolver for these soft preferences: I'd noticed the problem that the resolver wanted to rebuild packages like haskell98 against base 3, when they were already installed for base 4. This was because haskell98 did not constrain the choice of base and our soft preference was for base 3 vs base 4. So what I did was say that our soft preference should take into account if the exact same version of the package is already installed and pick the same version of the dependency. The theory is that if the same version is already installed against that version of the dep then it works to build against that version of the dep, and also it will usually mean we do not have to rebuild at all (unless other dep changes force a rebuild). So can you see what would go wrong for network-2.2.0.0? ... > Ian, did you not bump the version number for the network that GHC RC provides? > If the dependencies have changed, then cabal-install will try to reinstall it, > leading to this chaos. The installed network uses base-4 and syb so cabal-install decides to pick base-4 for network-2.2.0.0. That would be ok, but other dependencies have changed. The changed dep is that the syb dep has disappeared in the available version of network vs the installed version. Because dependencies have changed, it has to rebuild network-2.2.0.0 from source. Now it falls over because network-2.2.0.0 fails to build against base-4 even though the installed one was built against base-4. That's because the available and installed versions of network-2.2.0.0 are in fact different! Doh! cabal-install has to make this assumption that the installed and available instances of the same version of a package are really the same, that it can pick one or the other. The strategy we use is not to commit to the picking the available or installed instance until the last minute. At the end of install planning it "improves" the plan by replacing wherever possible, cases where we'd suggest rebuilding with packages that are already installed (and match the exact same deps). We cannot commit earlier to picking installed versions of things (at least not without a much clevered resolver) because that would constrain our choices too much and we'd very often fail to find consistent solutions. So yes, network-2.2.0.0 and all the other extralibs have to have new versions if anything has changed from their most recent releases. Indeed we should get them all released on hackage now. There is no need to wait for 6.10.1. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
