planning for ghc-6.10.1 and hackage

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri Oct 3 12:12:11 EDT 2008


On Fri, 2008-10-03 at 09:55 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> 
> > I propose two solutions:
> > 
> >       * Fix the dependency resolver
> >       * Add support in Cabal and Hackage for suggested version
> >         constraints
> 
> Simon PJ just came up with a suggestion for the second part.  The idea is this:
> 
> If we see a dependency like "base >= 3" with no upper limit, we should 
> satisfy it with base-3 in preference to base-4, on the grounds that the 
> package is much more likely to build with base-3.  This seems to be a 
> solution that works without any magic shims or "preference files" or 
> anything else.

The suggested version thing really turns out to be the same as saying we
should satisfy base >= 3 using base-3 rather than base-4. We want that
general mechanism anyway. So I think it's actually more general. We
don't need to tell the resolver about base specially, it just extends an
already existing notion of soft version preferences.

The current resolver allows for soft preferences on the installed state,
this just extends that to a general version preference. We want it
anyway to better manage transitions like QC1 -> 2 or Parsec 2 -> 3.

> Perhaps we could even go as far as saying "base >= 3.0" is equivalent to 
> "base == 3.0.*".  i.e. if you don't supply an upper bound, then we'll give 
> you a conservative one.  I wonder how much stuff would break if we did that.

The biggest problem is really just that the resolver has to deal with
two instances of the same package in its solution. It was designed from
the beginning with the assumption that it was accumulating version
constraints per-package name (and that all constraints on a package
version should be simultaneously satisfiable).

We should however have packages declare if they have opted into the
package versioning policy. Base would be one of them. We could then warn
users when they are using bad version ranges in dependencies on such
packages.

It'd have to be a field in the .cabal file. Any suggestions for a good
name?

package-version-policy: Yarr!


Duncan



More information about the Glasgow-haskell-users mailing list