cabal-install needlessly reinstalls an existing package

[judah]

With ghc-6.10.1, Cabal-1.6.0.1 and cabal-install-0.6 (or HEAD):

$ cabal install cabal-install --dry-run -v
[..]
Reading available packages...
Resolving dependencies...
[..]
selecting Cabal-1.6.0.1 (installed or hackage)
[..]
selecting process-1.0.1.1 (installed or hackage) and discarding filepath-1.0,
process-1.0.0.0 and 1.0.1.0
[..]
In order, the following would be installed:
Cabal-1.6.0.1 (reinstall) changes: process-1.0.1.0 -> 1.0.1.1
cabal-install-0.6.0 (new package)

The ghc package depends on Cabal-1.6.0.1 and process-1.0.1.0, so rebuilding Cabal to depend on process-1.0.1.1 causes ghc to have inconsistent dependencies. In particular:

$ cabal install cabal-install
[succeeds, but reinstalls Cabal-1.6.0.1]
$ cabal install ghci-haskeline
Resolving dependencies...
cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however
process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1

It seems like the right thing to do would be to use process-1.0.1.0 when building cabal-install.

[judah]

See also #470.

[duncan]

Please would you paste or attach the output of ghc-pkg list. I suspect it is the same problem as in #470, that there is overlap in the global and user package databases.

[judah]

I removed the only overlapping packages (haskell98-1.0.1.0 and Cabal-1.6.0.1) in the user db that I could see and tried again, and got the same error as above. ghc-pkg output is attached.

Incidentally, I'm pretty sure that those two overlaps were caused by this issue (rather than being the cause of it), since cabal install cabal-install will install a new Cabal-1.6.0.1 in the user DB (as I mentioned above).

[duncan]

Yes you're quite right. I can reproduce it. It's not the same as #470 though it does lead to that situation as you say.

So we pick Cabal and then process. We have not committed to picking the installed version of either yet. We end up picking the highest version of process. That then forces the choice of Cabal, we have to pick the available version because the installed version uses an older version of process.

We already try to pick the installed versions of packages however that heuristic is not enough here because there are multiple installed versions of process. To pick between them we should pick the one that would let us use the installed version of another package that we have already picked where we still have the choice of installed or available.

[duncan]

Actually, I think we can do this in another 0.6.x point release, probably 0.6.4. So that's not the immediate next point release which will be 0.6.2.

[kosmikus]

Probably hard to reproduce now, but if it's not already fixed in the topdown solver, I would at least expect the modular solver to be able to handle this properly.

[kosmikus]

Ok, I can reproduce a similar situation and it seems it's still handled as described in this bug. Using an imaginary version process-1.0.1.6 with ghc-7.0.4, I get:

In order, the following would be installed:
Cabal-1.10.2.0 (reinstall) changes: process-1.0.1.5 -> 1.0.1.6
deepseq-1.3.0.0 (new package)
text-0.11.1.13 (new package)
transformers-0.2.2.0 (new package)
mtl-2.0.1.0 (new package)
parsec-3.1.2 (new package)
network-2.3.0.11 (new package)
HTTP-4000.2.2 (new package)
zlib-0.5.3.3 (new package)
cabal-install-0.10.2 -bytestring-in-base (new package)
Warning: The following packages are likely to be broken by the reinstalls:
ghc-7.0.4
bin-package-db-0.0.0.0
Use --force-reinstalls if you want to install anyway.

Using the modular solver does not help, as it's using the same policy to pick the latest installed package by default, and doing this does not lead to an error, only to a reinstallation -- although that reinstallation breaks the ghc and bin-package-db packages.

We can fix this by using the --avoid-reinstalls flag. However, I don't want to make that flag the default, because it may lead to confusing install plans, as we can actually observe here:

In order, the following would be installed (use -v for more details):
Cabal-1.10.1.0
deepseq-1.3.0.0
text-0.11.1.13
transformers-0.2.2.0
mtl-2.0.1.0
parsec-3.1.2
network-2.3.0.11
HTTP-4000.2.2
zlib-0.5.3.3
cabal-install-0.10.2

Now, we get an older version of Cabal, which is also not what we really want.

We get the "correct" solution by passing `--constraint="process == 1.0.1.5":

Resolving dependencies...
In order, the following would be installed (use -v for more details):
deepseq-1.3.0.0
text-0.11.1.13
transformers-0.2.2.0
mtl-2.0.1.0
parsec-3.1.2
network-2.3.0.11
HTTP-4000.2.2
zlib-0.5.3.3
cabal-install-0.10.2

One option to fix problems like this one would be to actually try to find several install plans for a given problem and try to pick the "best". Picking an older uninstalled version should have a higher penalty as picking an older installed version.