package ghc depends on Cabal-1.5.5, which fails to load(ghchead,
claus.reinke at talk21.com
Sat Dec 6 06:50:42 EST 2008
>> > 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).
> It's more subtle than that, but yes.
but I don't want package installation to be subtle, I want it to be obvious.
And I definitely want it to be under my control.
If I have a package-version installed, and other packages depend on
package-version, cabal-install *should not try to second-guess* me, it
should follow my lead. At least until such time when cabal actually
understands module/package interfaces and can tell which combination
will fail and which won't.
>> 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.
> Hmm. That's easier said than done. It can only think it wants to
> re-install something if it knows what its dependencies are. That means
> it needs the .cabal file for the package. For things like the ghc
> package that is not available.
but 'ghc-pkg describe' etc are available, and cabal-install bootstraps
its own database from that information, right?
I still don't know how to get cabal.exe to do what I want (and it
doesn't help at all that 'cabal uninstall' is still not implemented, as
it makes experimentation painful).
There seems to be no way of keeping cabal.exe from wanting
to reinstall, so I tried bumping the array/containers versions of the
package I used to build my ghc, then reinstalling them. But that
only works part-way: I can cabal install glut without having cabal
reinstall array, but when I try to install a package that depends on
glut, cabal wants to reinstall glut(*):
In order, the following would be installed:
GLUT-22.214.171.124 (reinstall) changes: array-0.2.0.1 -> 0.2.0.0,
containers-0.2.0.1 -> 0.2.0.0
In summary, I don't seem to be able to use cabal.exe to install
the set of packages I want - I'm stumped.
(*) would it have helped if I had bumped the major version
numbers instead? or do I need to rebuild my ghc? or would
even that not help?
More information about the Cvs-ghc