cabal-install should rebuild dependants when a package is upgraded #124

Closed
bos opened this Issue May 24, 2012 · 7 comments

5 participants

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@shapr

Is this bug still current?

@kosmikus

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.

@jsl

This issue appears to be resolved based on comments. I propose closing, and re-opening a new issue if one is found.

/cc @tibbe

@tibbe tibbe closed this Feb 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment