GitLab

This information is passed via 'dist/setup-config'.

See https://github.com/haskell/cabal/issues/2046#issuecomment-53034455.

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: Edward Z. Yang <ezyang@cs.stanford.edu>

At the moment, $pkgkey is not supported for build reports, although in
principle we could add support for it, assuming that the configure step
succeeds.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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
database.

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
versions.

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: Edward Z. Yang <ezyang@cs.stanford.edu>

See #2023.

Now packages specified by directory or URL work with the --build-summary
option.

Fixes #2009.

Fixes #1337.

This reverts commit 03c134d5.

Committed by mistake.

Fixes #2016.

nkaretnikov authored Jul 26, 2014 and Mikhail Glushenkov committed Jul 26, 2014

Fixes #1962.

It looks like #1443 was actually fixed by the change from getModificationTime to
getModTime (which has higher resolution). The change to '>=' was not needed
because the code uses 'when', not 'unless'.

Thanks to Nikita Karetnikov for the heads-up.

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.

In accordance with @23Skidoo's comments on github.

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
confused.

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.

Fixes #1994 (hopefully).

Some stylistic changes have been made but otherwise this works in the same
manner as the original implementation.

A duplicate definition was somehow added while merging and was causing
build failures.