If packages are patched without any change in version number,
bad things can happen if one tries to cabal install additional packages
onto such a patched ghc.
At the moment, that seems to be the case for array and containers,
which were adjusted following the syb split, without changes in version
number (containers also seems to have gained some exports, foldrWithKey
and the like, again without version bump). Could this please be fixed?
Yes - the policy should be that we bump version numbers according to the
PVP as soon as an API change occurs. However, note that it's not practical
to do this *every* time an API change occurs, we only need to keep the
version number correct with respect to released versions of packages, not
unreleased versions. This is unlikely to cause a problem, though.
So that should allow cabal install to distinguish hackage versions from
the current darcs versions, but not different between-release darcs
versions, right? That might be sufficient (at least I don't recall a situation
where I wanted to update a corelib without rebuilding the ghc depending
on it), and seems to match what Duncan suggested.
All this "cabal install trying to be clever while packages lie about their
versions"
trouble, combined with "ghc gives you your linker error in raw form, completely
untainted by high-level Haskell/Cabal concepts" makes me wonder what else is
about to go wrong when lots of packages specify lots of precise and different
dependency versions, but at least there would no longer be any doubt which
dependency versions a ghc depends on.
Could the array/containers version bumps be done soon, please, so that
I can rebuild my ghc and try cabal install again? If I guess the new version
numbers wrongly, I'd have to rebuild and re-install everything again..
Ian - I think this might be different from the policy we agreed before, but
I can't remember where (if anywhere) we wrote it down. The difference is
that we hadn't considered the possibility of people trying to use cabal
install with a an unreleased HEAD build before, but I don't think there's a
good reason why this shouldn't work.
Isn't that going to become the rule, for anyone testing their code wrt HEAD,
given that there are now few packages in ghc HEAD itself, and everything
else comes via hackage/cabal install?
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
