GitLab

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.

It does not build with ghc-6.4.2, missing Functor instance for Either.

It's not specific to LHC. Normally we prevent upgrading of base
since it's unlikely to work and would normally be accidental.
However when the user explicitly asks to upgrade base then we
let them do that and they can keep the pieces when it breaks.

The server should ignore the dir part anyway but there's no
need to send it in the first place.

And slightly better intro guide to the main commands.