This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 20 Mar, 2010 1 commit
  2. 22 Oct, 2009 1 commit
  3. 18 Oct, 2009 1 commit
  4. 03 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Only apply preferences to base if its version is unbounded above · d31d1ca1
      Duncan Coutts authored
      Fixes ticket #485. This means that for constraints like:
          build-depends: base >= 3 && < 5
      we will pick version 4. However we will continue to apply the
      version 3 preference for things like:
          build-depends: base >= 3
      Where there is no upper bound on the version. Note that we now
      also ignore preferences for base given on the command line.
      We should implement #483 to split prefs from shims.
      d31d1ca1
  5. 31 May, 2009 2 commits
  6. 18 Feb, 2009 1 commit
  7. 19 Dec, 2008 1 commit
    • Duncan Coutts's avatar
      Use a more precise package substitution test in improvePlan · 0c063b53
      Duncan Coutts authored
      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.
      0c063b53
  8. 15 Dec, 2008 7 commits
  9. 07 Oct, 2008 1 commit
    • Duncan Coutts's avatar
      Fix selecting paired packages · 03ddfbb2
      Duncan Coutts authored
      Previously when we selected base 4 (and as a consequence
      slected base 3 too) we didn't properly trace the dependencies
      of base 3 so if nothing actually required base 3 then we ended
      up with base 3 in the solution but not with syb which it
      depends on. Consequently the solution was invalid.
      Now we select the paired package properly (hopefully).
      03ddfbb2
  10. 06 Oct, 2008 2 commits
  11. 05 Oct, 2008 3 commits
  12. 04 Oct, 2008 2 commits
    • Duncan Coutts's avatar
      Have Constraints.constrain report the excluded packages · 027922c8
      Duncan Coutts authored
      Each time we apply a constraint we can end up excluding some
      extra package. Report that list of packages because it is
      quite interesting information to get insight into what the
      resolver is actually doing.
      027922c8
    • Duncan Coutts's avatar
      Generalise the logging of selected and discarded packages · 80976686
      Duncan Coutts authored
      Allow for selecting several packages in one go.
      Currently when we select a package we only list the over versions
      of the same package that that excludes, and not the other packages
      we exclude by applying the dependency constraints of the selected
      package. In future we would like to do that so we now report the
      package name of discards not just the version. Though we do group
      by the package name to avoid too much repition.
      80976686
  13. 25 Sep, 2008 1 commit
  14. 31 Aug, 2008 1 commit
  15. 05 Aug, 2008 1 commit
    • Duncan Coutts's avatar
      Refactor BuildResult type and related types · 113a7d25
      Duncan Coutts authored
      Split BuildResult into Either BuildFailure BuildSuccess
      Make BuildSuccess contain info for docs and tests.
      Make PlanPackage use BuildSuccess and BuildFailure directly
      rather than being parameterised by any build result type.
      This has a knock on effect on lots of other types which
      were parameterised just because PlanPackage was.
      113a7d25
  16. 30 Jul, 2008 1 commit
  17. 10 Jun, 2008 1 commit
  18. 07 Jun, 2008 1 commit
    • Duncan Coutts's avatar
      Only inspect the needed parts of the installed and available indexes · 8d9cef62
      Duncan Coutts authored
      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.
      8d9cef62
  19. 02 Jun, 2008 5 commits
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Change the DependencyResolver type to take a per-package version pref · df953acf
      Duncan Coutts authored
      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.
      df953acf
    • Duncan Coutts's avatar
      Fix improvePlan so the index is updated incrementally · df947224
      Duncan Coutts authored
      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.
      df947224
    • Duncan Coutts's avatar
      Support top level dependency version constraints · 6835d7f6
      Duncan Coutts authored
      and error messages for when they're unsatisfiable or conflict
      6835d7f6
    • Duncan Coutts's avatar
      Implement plan improvement · e3f09219
      Duncan Coutts authored
      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.
      e3f09219
  20. 30 May, 2008 2 commits
    • Duncan Coutts's avatar
      As a heuristic, use topological order for the order of package choices · 3f4868d1
      Duncan Coutts authored
      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.
      3f4868d1
    • Duncan Coutts's avatar
      6a5c3556
  21. 29 May, 2008 2 commits
  22. 28 May, 2008 1 commit
    • Duncan Coutts's avatar
      First version of the top-down package dependency resolver · bc07102a
      Duncan Coutts authored
      This is a new dependency resolver that produces valid install plans.
      It works in polynomial time however because the search space is 
      exponential in size it is not guaranteed to find a solution even if
      one exists. It works by generating and then exploring the search
      space represented as a lazy tree. It uses constraints to prune
      choices and heuristics when guesses are necessary. Currently it can
      generate install plans for 99% of the packages on hackage. The
      remaining 6 packages should be doable with two extra tricks.
      It is not finished and is not yet usable in practice.
      bc07102a