package ghc depends on Cabal-1.5.5, which fails to load (ghchead, windows)

Claus Reinke claus.reinke at talk21.com
Fri Dec 5 14:30:04 EST 2008


>> Perhaps a HEADS UP is in order? Deciding about bumping cabal 
>> package version numbers before or after a release isn't sufficient
>> any more - they need to be bumped immediately when packages
>> change, or cabal-install won't play fair.
> 
> I think actually this is solvable.
> 
> The way the solver works is that it does not commit to using the
> installed version until the last possible minute. It does this because
> the installed versions have much tighter constraints on dependencies. It
> does a pass at the end to improve the solution by replacing available
> packages by already installed ones wherever possible.
> 
> Currently it does that by checking if all the deps are exactly the same.
> If they are not then it decides it's not suitable. We could relax that
> slightly by instead checking if all the constraints that picking the
> installed instance are consistent with the existing constraints. If they
> are consistent then we can pick the installed one (and add the
> constraints to the constraint set). If the conflict then we have to pick
> the available version and do a re-install.

That would help with the cabal-install side of the issue (don't replace a
package unless the version number differs). There is perhaps a secondary
issue there: if cabal-install thinks it should replace packages that are 
dependencies of packages that cabal-install doesn't know how to
rebuild, it should issue a warning (here: the ghc package), at least.

Still, shouldn't the .cabal version number always reflect the repo
status? Without automation, that is bound to keep going wrong,
so how about this

- darcs push could fail if a patch bundle doesn't change the version number
    ("error: all patch bundles should change the .cabal version number.
       the version numbering policy for this package is <insert>.
       if your patch bundle does not contain externally visible changes,
       just bump the patchlevel")

- darcs apply could fail if version numbers do not increase monotonically
    with each incoming patch bundle

- darcs pull should warn if incoming patch bundles don't change
    the version number

Claus



More information about the Cvs-ghc mailing list