cabal-install should rebuild dependants when a package is upgraded

[bringert]

Currently, when cabal-install upgrades a package, other packages that depend on it are not rebuilt.

Scenario: You have package A-1.0 and A-2.0, and B-1.0 which depends on A. B-1.0 is compiled against A-1.0. C then depends on A and B, and GHC picks A-2.0 and B-1.0. This breaks, because C now uses A-2.0 and B-1.0 uses A-1.0.

This could be made less of a problem if cabal-install would be able to reinstall all packages which depend on the new package. This might not always be what you want, so there should be a flag to turn it off.

Logic: When installing a new package Foo-X.Y, then each installed package which depends on Foo with a version range that includes X.Y should be reinstalled.

[duncan]

We'll need to know what the dependencies of installed packages are. ghc-pkg can tell us this information, though it requires calling ghc-pkg describe $pkgname once for every package, which takes a while.

[guest]

A real-life "war story" that seems to illustrate the problem, or at least be closely related:

I used 'cabal upgrade' to upgrade a bunch of packages, in particular bytestring and various regex-*, since I wanted to install something that depended on them.

Later, however, I tried to install Yi, which as it turns out was incompatible with the latest version of bytestring. I downgraded bytestring, but then had to rebuild vty (so it would be built with the older bytestring) and also unregister many of the newer versions of the regex-* packages, since Yi depended on them; with the newer versions installed, they were chosen to fulfill Yi's dependencies, but those newer versions depended on the newest version of bytestring, which was no longer installed.

[duncan]

The new install plan stuff guarantees that the above situation does not happen. There are never any inconsistent deps in a valid install plan. The new dep resolver will choose either to build C against A-1.0 or to rebuild B-1.0 to use A-2.0.

So it's less clear that we need this feature. That's not to say it's never needed, just that it's not the common case any more.

[kosmikus]

I think we should look at options to do this again, in connection with the modular solver.