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] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
