package ghc depends on Cabal-1.5.5, which fails to
duncan.coutts at worc.ox.ac.uk
Mon Dec 8 20:21:51 EST 2008
On Sat, 2008-12-06 at 11:50 +0000, Claus Reinke wrote:
> >> > 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.
Sorry, in general it's very subtle. On each users machine we're
composing software components that may never before have been tested
together and we're hoping it's going to work. We're using package
numbers and constraints as inexact proxies for statements about whether
the components we're composing will produce a result that is
type-correct. Even when simplified to package version numbers and
version constraints the problem of finding an installation plan is
NP-complete. In general there may be a large space of solutions with
only fuzzy preferences to decide which one to pick.
Sometime I think it's a wonder any of it works at all.
> 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.
No, there are times when using the installed version would lead to
conflicts and an invalid solution. That invalid solution would likely
lead to typechecking failing (eg cannot match
bytestring-0.9.0.1:ByteString against bytestring-0.9.0.2:ByteString).
> At least until such time when cabal actually understands
> module/package interfaces and can tell which combination
> will fail and which won't.
Since we are not there yet we have to make conservative assumptions. The
major assumption is that for each package in the solution, the
transitive closure of its dependencies must contain at most one version
of each package. A slight conservative simplification of this is that
the whole solution must contain at most one version of each package.
This is the reason that we sometimes cannot use the installed version of
a library, but if we re-installed the same version against different
versions of the dependencies then we could have a consistent solution.
This is the essence of what cabal-install's dep planner tries to do.
Yes of course we want it to be as predictable as possible and to produce
as good explanations as possible about why it may fail or why it may
produce slightly peculiar solutions. However actually doing that is
hard. My suggestion for doing it properly is to use a SAT solver with
unsatisfiable core minimisation, or some other proper constraint
satisfaction procedure. I'd guess it'd take about a month or so full
time to get it working well and producing good error messages in common
> >> 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?
That only says what it's built against now, not what it could possibly
be built against if we were able to re-build it.
> 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).
I think in this case you want to add a constraint to say that it must
use the installed version of a particular package.
> There seems to be no way of keeping cabal.exe from wanting
> to reinstall,
Right. There should be, but in practise one should not often have to use
> 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-126.96.36.199 (reinstall) changes: array-0.2.0.1 -> 0.2.0.0,
> containers-0.2.0.1 -> 0.2.0.0
That's because we have to use a consistent version of array and
containers. You'd need to rebuild everything against the other version.
cabal-install determined that it could not rebuild something else but
that it could rebuild GLUT to get a consistent solution.
> In summary, I don't seem to be able to use cabal.exe to install
> the set of packages I want - I'm stumped.
There are two solutions. Both involve changing cabal-install. One is the
change I suggested previously to use a more precise test when
determining if it is possible to use an installed rather that the
available version of a package. That should be done anyway. The other is
to allow user-supplied constraints on both the version number and
installed status of packages. These constraints are used internally, but
it would be handy to expose them for advanced users or for workarounds.
> (*) 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?
No, there is no particular interpretation on the version numbers.
More information about the Cvs-ghc