GitLab

Don't bother putting the server url into each report
since we do not want to upload that information anyway.

and add a function to parse a whole logfile of reports

This is so that we remember which server to send the reports to.
This is pretty important if you're using a private as well as a
public hackage server.

Instead of just using the latest version we use the best version
according to the following preferences in priority order:
- the same version as cabal-install was itself built with
- the same major version number as cabal-install was built with
- a stable version of Cabal (even second digit of major number)
- the latest version

The available package index is loaded lazily so if we can avoid
forcing all the packages then we can save a huge amount of slow text
parsing. So select out the maximal subset of the index that we could
ever need based on the names of the packages we want to install. For
the common case of installing just one or two packages this cuts
down the number of packages we look at by a couple orders of
magnitude. This does not help with the installed index which is read
strictly, though most people do not (yet) have hundreds of installed
packages, so that's less of an immediate problem.

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.