[Hackage] #485: preference on base version should only be applied for open constraints

Hackage trac at galois.com
Sun Feb 1 21:12:53 EST 2009


#485: preference on base version should only be applied for open constraints
---------------------------------+------------------------------------------
  Reporter:  duncan              |        Owner:         
      Type:  enhancement         |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.6.0.1
  Severity:  normal              |     Keywords:         
Difficulty:  unknown             |   Ghcversion:         
  Platform:                      |  
---------------------------------+------------------------------------------
 Currently we apply the preference on the base version. That means that if
 you have base 3 and 4 available then for dependencies like:

 {{{
 build-depends: base >= 2
 }}}
 or
 {{{
 build-depends: base >= 3 && < 5
 }}}

 Then we end up picking base 3. That makes perfect sense in the  first
 case. In the first case the developer clearly did not think about base 4.
 However in the second case they clearly have thought about it and yet we
 end up picking base 3. On balance it is probably better to pick base 4 in
 the second case even though both are allowed.

 One suggestion for how to handle soft constraints on the version of base
 is to say that we only apply the preference if the version is not bounded
 above. If it is bounded above then we use no preference and end up picking
 the highest version available.

 This policy cannot be expressed in the simple preferred versions syntax.
 It's probably ok to hard code it for base for now. This will require
 generalising the interface to the constraint solver to supply preferences
 in a slightly different form. It may need to be as a function from a list
 of possible versions to the selected version. The function would also be
 supplied with the package it's for, the dependency and the list of
 installed versions since it may want to take any of these into account and
 it is needed to express the above policy.

 This is related to the splitting of preferences into real preferences and
 hacks (see #483).

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/485>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects


More information about the cabal-devel mailing list