This project is mirrored from Pull mirroring updated .
  1. 24 Aug, 2014 1 commit
  2. 22 Aug, 2014 2 commits
  3. 19 Aug, 2014 1 commit
  4. 18 Aug, 2014 1 commit
  5. 13 Aug, 2014 2 commits
  6. 04 Aug, 2014 3 commits
    • Edward Z. Yang's avatar
      Disable reinstalls with distinct package keys for now. · d3a696a3
      Edward Z. Yang authored
      Duncan requested that cabal-install not try to put multiple entries in the
      package database with duplicate package IDs (foo-0.1) until other tools (in
      particular GHC) are able to deal with situation in a better way.  We want to
      revert this commit soon, since with this turned on, we basically don't get any
      benefit from the package key refactoring (no deliverance from Cabal hell.)
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Add $pkgkey template variable, and use it for install paths. · 1d33c8f5
      Edward Z. Yang authored
      At the moment, $pkgkey is not supported for build reports, although in
      principle we could add support for it, assuming that the configure step
      Signed-off-by: default avatarEdward Z. Yang <>
    • 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 <>
  7. 02 Aug, 2014 2 commits
  8. 29 Jul, 2014 3 commits
  9. 27 Jul, 2014 4 commits
  10. 25 Jul, 2014 2 commits
  11. 21 Jul, 2014 1 commit
    • Isamu Mogi's avatar
      Read installed package info file as UTF-8 · 44a261d4
      Isamu Mogi authored
      Currently installed package info file is written in UTF-8. So UTF-8
      should be used explicitly or it can cause "invalid byte sequence"
      error if system encoding is incompatible to UTF-8.
  12. 17 Jul, 2014 3 commits
    • Mikhail Glushenkov's avatar
      Unbreak the build. · 337f9cd7
      Mikhail Glushenkov authored
    • Keshav Kini's avatar
      Remove first-person and unix-specific language · 9052ff49
      Keshav Kini authored
      In accordance with @23Skidoo's comments on github.
    • Keshav Kini's avatar
      Better message when new cabal-install available · 12c1cfb7
      Keshav Kini authored
      A common mistake new users of cabal-install seem to make is to run
      `cabal update`, see the message "Note: there is a new version of
      cabal-install available.", accordingly install a new version of
      cabal-install by doing `cabal install cabal-install`, neglect to make
      sure that the newly installed cabal-install executable is in their path,
      and continue to run the cabal-install executable they had before.  The
      next time they do `cabal update`, they see the same message and become
      This commit changes the message in question to be more informative and
      helpful.  In particular, if the currently running version of
      cabal-install is older than the newest version available from hackage,
      the user will not be told simply that "there is a new version of
      cabal-install available", but rather will be informed exactly what new
      versions are available, and what version they are currently running,
      along with a hint to change their $PATH variable if it turns out they're
      not running the version of cabal-install they thought they were.
  13. 11 Jul, 2014 1 commit
  14. 08 Jul, 2014 2 commits
  15. 29 Jun, 2014 1 commit
  16. 28 Jun, 2014 3 commits
  17. 26 Jun, 2014 1 commit
  18. 25 Jun, 2014 2 commits
  19. 24 Jun, 2014 5 commits