HEADS UP: patches, package versions, and cabal-install

[Claus Reinke]

>> 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