Now this problem may be completely resolved in newer versions of cabal-install, but I think having a large number of packages in the global package database pegged at specific versions is a very strong recipe for reintroducing version hell. Coming back to yaml: it depends on conduit. Suppose after the HP is released, I release a new version of conduit. And suppose some other package (say, xml-conduit) depends on this newer version. What happens when the user tries to install a package that depends on the newer xml-conduit and yaml at the same time? Ideally I'd want them to get yaml recompiled against a newer version of conduit, but conflicting user and global databases can be a very sore point.
But this is exactly the point of the "Haskell Platform": given some set of specific package versions, install them at the very beginning, and have all other packages be built with those packages. If you want to update one of those packages, you are almost definitionally going to have to rebuild--and this won't go away until Haskell libraries with no API changes get binary compatibility. Edward