This project is mirrored from Pull mirroring updated .
  1. 04 Aug, 2014 1 commit
    • 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 <>
  2. 16 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Implement "reexported-modules" field, towards fixing GHC bug #8407. · 62450f9a
      Edward Z. Yang authored
      Re-exported modules allow packages to reexport modules from their
      dependencies without having to create stub files.  Reexports of the same
      original module don't count as ambiguous imports when module finding
      occurs.  The syntax is:
          "orig-pkg" OrigName as NewName
      You can omit 'as NewName', in which case it is reexported as the same
      name.  Self referential aliases work too; however, they're only visible
      to packages which depend on this package.
      Left to future work: just provide a module name 'OrigName', where ghc-pkg
      figures out what the source package is.
      Signed-off-by: default avatarEdward Z. Yang <>
  3. 02 Feb, 2014 1 commit
  4. 23 Oct, 2011 1 commit
  5. 18 Oct, 2011 1 commit
  6. 08 Aug, 2011 1 commit
  7. 19 Jun, 2011 1 commit
  8. 17 Jun, 2011 1 commit
  9. 31 Jan, 2011 1 commit
  10. 22 Aug, 2009 1 commit
  11. 06 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Add a unuque identifier for installed packages (part 2 of 9) · fb685e8c
      Simon Marlow authored
      Note: this patch doesn't build on its own, you also need the rest of
      the patch series.
      Compatibility with older GHCs.  When reading a package database
      created by an older version of GHC without installedPackageIds, we
      have to fake an InstalledPackageId for the internal
      So, when reading in an InstalledPackageInfo from an older GHC, we set
      the installedPackageId to be the textual representation of the
      PackageIdentifier: i.e. <package>-<version>.  Now, previously the
      depends field of InstalledPackageInfo was [PackageIdentifier], and is
      now [InstalledPackageId], so we will read each PackageIdentifier as an
      InstalledPackageId (a String).  The dependencies will still point to
      the correct package, however, because we have chosen the
      installedPackageId to be the textual representation of the
  12. 02 Dec, 2008 1 commit
  13. 04 Jul, 2008 1 commit
  14. 28 Jun, 2008 1 commit
    • Duncan Coutts's avatar
      Update module headers · 0c993c84
      Duncan Coutts authored
      Use as the maintainer in most cases except for
      a few which were pre-existing modules copied from elsewhere or modules
      like L.H.Extension which really belong to
      Remove the useless stability module. We have more detailed information
      on stability elsewhere (in the version number and user guide).
      Add more top level module documentation, taken from the source guide.
  15. 26 Jun, 2008 2 commits
  16. 21 Jun, 2008 1 commit
    • Duncan Coutts's avatar
      Add compat InstalledPackageInfo types for older GHCs · 7c4b1aa1
      Duncan Coutts authored
      We need these types for their Read instances so that we
      can still read older GHCs package db files when we make
      changes to the current InstalledPackageInfo type, or the
      types contained in it, like PackageIdentifier or License.