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