GitLab

Allows us to use cabal-install to build packages where we build the
Setup.hs script using an older version of the Cabal library.
This is important for packages that claim to need an older version
and it's also pretty useful for testing.

It is important to know which version of the Cabal lib the setup
script has been built with because it affects what flags we can pass
to it. So we now store the version in dist/setup/setup.version.
If the version number changes then we rebuild the setup binary.

Otherwise we end up saying packages failed because they depend
on themselves which failed to install, which is silly.

The reverse deps may have already failed due to depending on another
failed package. So do not assume all reverse deps are in the
configured state. If they are in the failed state then ignore them.

This is because a package can depend on several packages and if one
of the deps fail then it fails but it still depend on the others
that did not fail. This fixes an assertion failure in larger builds.

Although it is expensive, we want to catch problems early.

So we don't end up downloading the index from hackage twice.

The new resolver is a significant change in behavior so it's
useful to know when people report problems.

Time for wider testing.

Up to now 'upgrade' took no args and tried to upgrade all installed
packages to the latest versions. It retains that mode but also has
a new mode rather like 'cabal install'. The difference is that with
$ cabal install foo
it means install latest version of foo but otherwise prefer the
installed versions of deps of foo, while
$ cabal upgrade foo
means install the latest version of foo and also the latest
versions of all the dependencies of foo.

And add a few global package version pref policies and use them in
ordinary install and upgrade. For install we use a policy that says
that we prefer the latest version of a package that we specifically
request and prefer the installed version of any other package. For
upgrade we simple always prefer the latest version. One can imageine
other policies where we prefer the latest version for only some
interesting subset of packages and installed otherwise.
No resolvers actually make use of this preference yet.

It's important since later packages can depend on earlier ones having
been changed from configured to pre-existing. That is afterall the
whole point of considering them in reverse toplogical order.
Also, remove duplicates in the dependencies list of installed
packages since ghc-pkg does not currently prevent duplicates in (eg
multiple depends on the same version of base). See ghc bug #2230.

and error messages for when they're unsatisfiable or conflict

It was passing the value as another argument, distinct from the flag.

The idea is to improve the plan by swapping a configured package for
an equivalent installed one. For a particular package the condition
is that the package be in a configured state, that a the same version
be already installed with the exact same dependencies and all the
packages in the plan that it depends on are in the installed state.

The general case in exploring the state space is that we have a set of
choices (package names) and for each choice we have a number of
versions of that package we could pick. If there's only one version of
a package then we make that choice first. Otherwise we have to pick
some package and select one of the available versions. The question is
which package should we make a choice for first? Previously we picked
completely arbitrarily. Surprisingly this actually works pretty well.
An improvement is to pick packages in topological order. This works
better because it allows dependencies from earlier choices to
constrain our later choices.

And show progress messages at verbosity level 2.

nd clean up header info

rather than Either and structured error type [Dependency]. The reason
we cannot use that as a structured error type any more is because
missing dependencies is not the only failure reason. There are
several reasons, several of which are pretty complex. For now we'll
have to do with a human readable message. Perhaps we may be able to
find a common structured type that the different dep resolvers can
all agree on. I'm not hopeful however as error reporting seems to be
closely tied to the dep resolution approach.

rather than the local definitions

This is a new dependency resolver that produces valid install plans.
It works in polynomial time however because the search space is 
exponential in size it is not guaranteed to find a solution even if
one exists. It works by generating and then exploring the search
space represented as a lazy tree. It uses constraints to prune
choices and heuristics when guesses are necessary. Currently it can
generate install plans for 99% of the packages on hackage. The
remaining 6 packages should be doable with two extra tricks.
It is not finished and is not yet usable in practice.

Previously if the base package was available on hackage then the dep
resolver might try to upgrade it. Unfortunately that's almost
certainly technically impossible at the moment. So now since the dep
resolver does not see these available packages it cannot pick them.
This should fix ticket #174.

It shares most code anyway.
Also fixes ticket #260 becuase we use the right entry point now.