patch applied (cabal-install): Disable cabal upgrade and add cabal install --upgrade-dependencies

[Duncan Coutts]

On Wed, 2010-06-02 at 12:32 +0200, Peter Robinson wrote:
> On 1 June 2010 18:52, Duncan Coutts <duncan.coutts at googlemail.com> wrote:
> > On Tue, 2010-06-01 at 16:48 +0200, Peter Robinson wrote:
> >> On 31 May 2010 15:18, Duncan Coutts <duncan.coutts at googlemail.com> wrote:
> >> > Mon May 31 06:03:06 PDT 2010  Duncan Coutts <duncan at haskell.org>
> >> >  * Disable cabal upgrade and add cabal install --upgrade-dependencies
> >> >  cabal upgrade now gives an error message telling people to use install
> >> > or, if they know what they're doing, install --upgrade-dependencies
> >>
> >> How about also adding a reference to 'cabal install world'? I think that's the
> >> behaviour most people actually want when running upgrade (at least I do :) ).
> >
> > Yes, I was thinking about that. I think we need a little more work
> > before the world feature is recommended to the masses.
> >
> > http://hackage.haskell.org/trac/hackage/ticket/695
> >
> > As you point out, we would really need to start tracking programs.
> 
> Yes, I guess tracking programs will be necessary, although this might not be as
> urgent as the dep resolver problems.

Hmm, not sure.

> I suppose this is also highly related to the uninstall feature.

It's related but I don't think one strictly depends on the other.

> > The other thing I'm not yet convinced about is keeping just the flags in
> > the world file. I suspect we'll need more eventually and should perhaps
> > plan the format with that in mind. Also currently we do not properly
> > assign flags to individual packages, that's not the fault of the world
> > feature, it's a problem elsewhere in cabal-install.
> 
> You're probably right. For the time being, however, I would settle for
> getting the simple file format to work without problems. :)

So long as we can upgrade it later...

> > Don't get me wrong, the world feature is definitely what we need (and
> > works well for distros) but generally I think we need more experience of
> > how it works in practise. I suspect one of the first things we'll find
> > is that the dep resolver runs into problems when trying to install
> > world. While it could find install plans for each package individually
> > it might not be able to find a plan for all the world packages
> > simultaneously. We may need some significant improvements in the solver
> > and we might have to do things like treating the flags etc as
> > suggestions rather than hard "all or nothing" constraints.
> 
> Hmm, yes I've noticed running into problems once the world file reaches
> >10 lines. At the moment I don't really see how to make the current resolver
> algorithm handle this issue, but I'll need to take a closer look at the code.

It is a question of what behaviour we want. Currently these two commands
mean different things:

cabal install foo; cabal install bar
vs
cabal install foo bar

The key difference is that the latter guarantees that both foo and bar
can be used together in a single program, with consistent dependencies.
With the former, it might be that the two packages disagree on the
version of a common dependency.

So currently cabal install world means try to install all the world
packages such that they all have consistent dependencies. This gets
increasingly difficult with more packages, and sometimes it is
impossible.

Having a smarter dep resolver will help find the consistent install plan
for all world packages in more situations.  It is also worth considering
using a looser consistency model where we make sure the deps of each
package individually are consistent, but do not provide global
consistency. The downside is that it will not necessarily be possible to
use all combinations of packages at once.

Duncan