[Hackage] #220: detect inconsistent package dependencies
#220: detect inconsistent package dependencies -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- Now that packages are more fine grained and upgradeable we're commonly getting situations where we build a package that uses two other packages that were built against different versions of another common package. The most common example in the wild at the moment is people installing `bytestring-0.9.0.4` in addition to the `bytestring-0.9.0.1` that came with ghc-6.8.2 and then half their packages are built against one version and half against the other and when they try to use packages built against different versions we get a type error about `bytestring-0.9.0.1:Data.ByteString.ByteString` not being the same as `bytestring-0.9.0.4:Data.ByteString.ByteString`. Cabal could and should detect this situation, and `cabal-install` should plan around it in its dependency resolution algorithm. However in both cases we require the dependency information of the existing installed packages. See http://hackage.haskell.org/trac/ghc/ticket/1839 The simplest thing is to get the full `InstalledPackageInfo` for all the packages in the package databases. From that we can find all the dependencies. When we do find this situation it is not guaranteed to cause a compiler error, it's just rather likely. So it's not obvious if Cabal should warn or error. `cabal-install` could try to fix up inconsistencies but in general only by re-installing existing packages against different versions of their dependencies. The longer term solution is to allow installing multiple instances of the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/220 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
The longer term solution is to allow installing multiple instances of
#220: detect inconsistent package dependencies ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross@soi.city.ac.uk): Replying to [ticket:220 duncan]: the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc. Couldn't this lead to an exponential explosion in the number of package instances? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/220#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
hmm, couldn't figure out a way to login to reply. Hackage wrote:
The longer term solution is to allow installing multiple instances of
Replying to [ticket:220 duncan]: the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc.
Couldn't this lead to an exponential explosion in the number of package instances?
only if you *actually* install all possible combinations, which seems unlikely. If you're worried about all the old cruft hanging around taking up space, maybe looking at Nix's garbage collection and other features would be good sharing of experience. Maybe (with the user's permission) pre-emptively upgrading some things sometimes would help... not sure. -Isaac
On Sun, 2008-01-27 at 17:44 -0500, Isaac Dupree wrote:
hmm, couldn't figure out a way to login to reply.
It says on the front page :-) username "guest" and password "haskell'" (note the apostrophe at the end)
Hackage wrote:
The longer term solution is to allow installing multiple instances of
Replying to [ticket:220 duncan]: the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc.
Couldn't this lead to an exponential explosion in the number of package instances?
only if you *actually* install all possible combinations, which seems unlikely. If you're worried about all the old cruft hanging around taking up space, maybe looking at Nix's garbage collection and other features would be good sharing of experience.
Right, Nix uses GC to clean up old combinations that are not used any more. Of course Nix is a proper package manger so it knows all code that uses a package where as we do not. Duncan
#220: detect inconsistent package dependencies ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): This is a serious problem, package developers have responed by hard-coding package versions which they happen to know work with ghc-6.8.2 without hitting this problem. For example [http://hackage.haskell.org/cgi-bin/hackage- scripts/package/yi-0.3 yi-0.3] specifies: {{{ build-depends: bytestring ==0.9.0.1 -- >= 0.9 && < 0.9.0.4 }}} It is clear that the real dependency is {{{>= 0.9 && < 0.9.1}}} because the API is exactly the same for the `0.9.0.x` series. However because `yi` depends on the `ghc` package, with `ghc-6.8.2` we would hit the problem that the `ghc` package is built with `bytestring-0.9.0.1`. So hard coding the `bytestring` version is a quick fix but it means of course that this package will not work with any other version of ghc and cannot take advantage of rebuilding the ghc package to use a different bytestring version. The solution is for the package manger to resolve this problem and not for packages to hard code binary dependencies, they should stick to api dependencies. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/220#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#220: detect inconsistent package dependencies
----------------------------+-----------------------------------------------
Reporter: duncan | Owner:
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: Cabal library | Version: 1.2.3.0
Severity: normal | Resolution: fixed
Keywords: | Difficulty: hard (< 1 day)
Ghcversion: 6.8.2 | Platform:
----------------------------+-----------------------------------------------
Changes (by duncan):
* status: new => closed
* resolution: => fixed
Comment:
{{{
Tue Feb 19 00:01:39 GMT 2008 Duncan Coutts
participants (3)
-
Duncan Coutts -
Hackage -
Isaac Dupree