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
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
