• Edward Z. Yang's avatar
    Implement package keys, distinguishing packages built with different deps/flags · 41610a0b
    Edward Z. Yang authored
    Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
    would only be one instance of it in the installed packages database.  This
    posed problems for situations where you want a package compiled twice against
    different sets of dependencies: they could not both exist in the package
    Package keys are a hash of the package ID and package
    dependencies, which identify a package more uniquely than a package ID, but less
    uniquely than an installed package ID. Unlike installed package IDs, these can
    be computed immediately after dependency resolution, rather than after
    compilation.  Package keys require support from the compiler.  At the moment,
    only GHC 7.10 supports package keys (the reason is that old versions of GHC
    do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
    package database matches with the -package-name embedded in an hi file; so
    the format is fixed.) We fallback to package keys == package IDs for old
    Note: the ./Setup configure fallback script does not try particularly hard to
    pick consistent sets of dependencies.  If your package database is too difficult
    for it to resolve, manually provide installed package IDs or use cabal-install's
    dependency solver.
    Note: This patch *suspends* the reinstall check unless it would result in
    a different package, so cabal-install will now happily reinstall foo-0.1
    compiled against bar-0.2 if foo-0.1 already exists.
    Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
IPI641.hs 4.11 KB