[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
#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 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.
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:
Replying to [ticket:220 duncan]:
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.
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:
Replying to [ticket:220 duncan]:
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.
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 <duncan@haskell.org> * Detect broken and inconsistent package deps We now check for packages that are broken due to their dependencies having been unregistered. We fail and print a fairly sensible message in this case. We also check for inconsistent dependencies and give a warning saying which packages are depending on inconsistent versions of a third. This is a warning not an error because it does not always lead to failure. Hopefully it'll help people who are otherwise just running into random compile errors. This fixes ticket #220. }}} We now get warnings like this: {{{ Configuring Foo-1.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package rss-3000.0.1 requires HaXml-1.13.3 package Foo-1.0 requires HaXml-1.19.2 }}} This was for a `Foo-1.0` package that depended on `rss` and `HaXml` where both `HaXml-1.13.3` and `HaXml-1.19.2` were available but `rss` had been built against the older `HaXml-1.13.3`. So by default we're still picking the latest `HaXml` version but now we warn that we got inconsistent versions. In this example it would be possible to avoid the inconsistency by picking `HaXml-1.13.3`. That is the next step. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/220#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects
participants (3)
-
Duncan Coutts -
Hackage -
Isaac Dupree