On 03/10/2010 00:12, Brandon S Allbery KF8NH wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 10/2/10 18:07 , Christian Höner zu Siederdissen wrote:

...

cd syb-0.2.1 * remove base<4.3 constraint from syb.cabal cabal install * syb-0.2.1 is now installed and works!

$ cabal install parsec-3.1.0 cabal: cannot configure syb-0.2.1. It requires base>=4.0&& <4.3

This is rather annoying: the constraint is solved (eg. syb is installed) but we /still/ assume that we can not continue. So obviously, I would like to be able to have cabal assume constraints fullfilled if the package is installed.

This is unsafe because the package database (which isn't maintained by cabal, but by ghc; see the ghc-pkg command) doesn't store the constraints. So cabal can't tell if that *particular* build was against the version of base it needs for everything else.

Sure it can: $ ghc-pkg field haskell98 depends depends: array-0.3.0.1-d7acfe6d19e77c2d80d16a9f0bc16697 base-4.2.0.2-6ca19098c3531da73f1940ce836e19d8 directory-1.0.1.1-4b73b609a785b25115a63a1f7bf6928d old-locale-1.0.0.2-0c1a4b40f2d3b9f6b725f54c00fe0923 old-time-1.0.0.5-cfc209473b38d8ca51f7dbeea24c4f0f process-1.0.1.3-e944f15cf7e7ec567f14bf379c37cadd random-1.0.0.2-049b2f84143b7536808f44f17ec734b4

(ghc can have multiple versions of base around; see the 6.10 series. I *think* ghc is constrained to only supporting it for different major versions, but it can't tell Cabal that.)

Now, it is arguable that if there is no different release of base in the package database then it should assume the visible release is the one used; but you again run into the limitations of ghc-pkg. If I "ghc-pkg hide" a given package release, dependents of that package don't also get hidden because (again) ghc-pkg doesn't store that information.

hiding packages makes no difference to Cabal, it is only for setting the packages that are visible to GHCi and ghc --make.

So now you end up with the same problem except it will show up when you try to use one of the dependents, and (worse) because Cabal can't tell this happened you will at best get an unexpected type mismatch at compile time and at worst the program will compile but dump core (if the mismatch is in base. It's hard to validate that runtimes are compatible, and base is very tightly bound to the runtime).

I'm afraid I'm not following - I thought we'd eliminated the possibilty of incorrect combinations of packages by using the ABI hash to identify dependencies (in GHC 6.12). Could you describe exactly how you get into this situation? Cheers, Simon

- -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkynvHgACgkQIn7hlCsL25XttACfQ+9G4bIAOnQVwJddDBizaPba uU4AoJjFXPkeqcloqp8w2COQ4I0bh+nk =sZhw -----END PGP SIGNATURE----- _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Sat, Oct 2, 2010 at 8:29 PM, Daniel Fischer wrote:

Yes, cabal looks at the package-index to find out the required dependencies, it doesn't know where you have local source files.

Actually, this is cabal-install. If you 'cabal unpack' then 'runhaskell Setup.hs configure' and 'runhaskell Setup.hs build', maybe it works =). But the suggestion about increasing the version number is good anyways. Cheers! =) -- Felipe.