(Imported from Trac #131, reported by bringert on 2007-05-23)
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.
(Imported comment by @dcoutts on 2007-05-23)
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.
(Imported comment by guest on 2008-01-12)
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.
(Imported comment by @dcoutts on 2008-01-24)
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.
(Imported comment by @kosmikus on 2008-06-07)
I think we should look at options to do this again, in connection with the modular solver.
Is this bug still current?
I think that what the original reporters suffered from were problems that do no longer arise. However, there's still the question whether installing a new version of a package A should (optionally) cause visible reverse dependencies of A to be built against the new version of A, too. This is even more interesting if the change on package A is not installing a new version, but reinstalling an existing one. cabal-install-0.14.0 will warn about visible reverse dependencies of A potentially being broken then, but it'll not offer a way to try to "upgrade" them.
This issue appears to be resolved based on comments. I propose closing, and re-opening a new issue if one is found.