GitLab

This should fix a long-standing bug with http proxies (ticket #352)
It should also make downloads faster, or at least use less memory.

Really old versions of cabal-install generated a default config
containing "compiler: GHC". Sadly the new way we generate the
config file parser from the command line parser means we end up
with a case-sensitive parser as it only matches the exact
command line flags. So we hack it and add in a traditional
parser for that field only. Really the command line and config
file infrastructure needs rewriting again. Sigh.

Should fix ticket #365

Hopefully more useful and more robust. In particular it does not
download and install packages where suitable versions are already
installed. It also checks for deps.

In particular fixes a problem (ticket #439) where we required the
installed version of ghc-prim with compilers that do not have that
package such as ghc-6.8 and older, hugs, nhc, lhc etc.

For example it will print:
Warning: The package list for 'hackage.haskell.org' is 16 days old.
Run 'cabal update' to get the latest list of available packages.

It is probably not sufficiently useful to justify the space it takes.

Previously we omitted the line if it was not installed, or was
not available. However that confused people because it was not
obvious that it would list both. Now it shows something like:
 * foo
       Latest version available: 1.0
       Latest version installed: [ Not installed ]

Ticket #413

Put the general info message at the top and make the explanation of
installing a hackage package somewhat clearer.

Examples: 
  cabal install                     Package in the current directory
  cabal install foo                 Package from the hackage server
  cabal install foo-1.0             Specific version of a package
  cabal install 'foo < 2'           Constrained package version

So we end up with:
  Hackage password: 
  Uploading test.tar.gz...
rather than:
  Hackage password: Uploading test.tar.gz...

Fixes ticket #394.

This is where we take a valid plan and we "improve" it by swapping
installed packages for available packages wherever possible. This
change is to the condition we use in deciding if it is safe to use
the installed package in place of a reinstall. Previously we checked
that the dependencies of the installed version were exactly the same
as the dependencies we were planning to reinstall with. That was
valid but rather conservative. It caused problems in some situations
where the installed package did not exactly match the available
package (eg when using development versions of a package or of ghc).
What we do now is test if the extra constraints implied by selecting
the installed version are consistent with the existing set of
constraints. This involves threading the constraint set around. In
theory this should even cope with adding additional packages to the
plan as a result of selecting an installed package.

We want to stop cabal-install from accidentally trying to upgrade
the base package since this doesn't work in most cases. We used to
achieve that by deleting the base package from the available package
index. We now do it by leaving the package index as is and instead
adding a constraint that we pick only an installed version of base.
This is a nicer hack and has the potential to give better error
messages.

It now carries around the original version of the database
purely so that it can do a much more extensive consistency
check. Packages are never gained or lost, just transfered
between pots in various slightly tricky ways.

A rather subtle bug. The code was actually correct but the transitionsTo
assertion was not accounting for a transition between the case where
a package's available version had been excluded and then the whole thing
got excluded by a version constraint. It counted one side as a loss
without a corresponding gain on the other side.

This behaves just like the preferred-versions file in the hackage index
but it can be specified on the command line or in a config file.

We still provide a default global policy, but now we give a
list of per-package preferences which can be on the version
or installed state. Later preferences override earlier ones.

Diagnosis and patch from Valery V. Vorotyntsev.

Connect up the existing user interface with the new dep resolver api.

This should be useful for things like preventing upgrading
the base package for ghc.

This lets us specify constraints for packages that are not targets.

It used to be a type alias.

Also fix a bug for tar files that contain entries for files
without preceding entries for the directories they are in.

Make the names more regular and set up the various flags
in a more regular way.

This would let us build with ghc-6.4 or nhc if it were not for other issues.