This project is mirrored from Pull mirroring updated .
  1. 05 Nov, 2015 1 commit
  2. 03 Nov, 2015 1 commit
  3. 02 Nov, 2015 5 commits
    • Andres Löh's avatar
      Merge pull request #2906 from dcoutts/master · f2278fc2
      Andres Löh authored
      Solver: limit where package target constraints apply
    • Duncan Coutts's avatar
      Solver: limit where package target constraints apply · 13dceb5b
      Duncan Coutts authored
      When we have a target like "foo-1.0", in terms of solver input this
      gets turned into a target package name of "foo" and a (labelled)
      constraint of "foo == 1.0". This constraint is of course to ensure
      that we pick the right target. However, with the recent addition of
      qualified package goals we have the possibility of picking multiple
      versions of the same package (e.g. via setup deps). If we have a
      constraint like "foo == 1.0" apply everywhere then it becomes
      impossible to pick multiple versions of package "foo", which may
      mean we cannot find a solution at all. But the constraint for the
      target need not apply everywhere, it's just to ensure that for the
      "main" instance, we pick the right version.
      This patch makes that precise. We have these constraints arising
      from targets apply only to package name goals that are suitably
      unqualified: qualifications arising from independent goals and from
      base version trickery are ok, but qualifiactions from setup deps
      are not. Or to put it another way, these target constraints do not
      apply to goals arising as the result of setup dependencies.
      As a more concrete example, this allows a situation where a package
      needs an old version of Cabal as a setup dep, but a new version of
      Cabal is also present in the main part of the solution as a normal
      library dep. Whenever we solve for that main Cabal lib as a target
      it would previously fail (it would be impossible to satisfy the
      conflicting constraints on the Cabal setup dep) and it now works.
    • Herbert Valerio Riedel's avatar
      Relax upper bound on process to allow process-1.4 · 75d2807a
      Herbert Valerio Riedel authored
      The only change between process 1.3 and 1.4 is:
      "Added child_user and child_group to CreateProcess for unix. #45"
      And the relevant code in Cabal doesn't seem affected by those additional
    • Mikhail Glushenkov's avatar
      Merge pull request #2905 from phadej/travis-ghc-7.2 · aa835ea0
      Mikhail Glushenkov authored
      	Bump lower bounds of dependencies 
    • Oleg Grenrus's avatar
  4. 01 Nov, 2015 2 commits
  5. 29 Oct, 2015 1 commit
  6. 28 Oct, 2015 4 commits
  7. 27 Oct, 2015 12 commits
  8. 23 Oct, 2015 1 commit
  9. 22 Oct, 2015 9 commits
  10. 20 Oct, 2015 1 commit
  11. 19 Oct, 2015 3 commits
    • Mikhail Glushenkov's avatar
      Comment. · cf515d60
      Mikhail Glushenkov authored
    • Duncan Coutts's avatar
      Change a few InstallPlan functions to use all dependencies, including setup deps · 01d863ef
      Duncan Coutts authored
      When setup deps were introduced "Add ComponentSetup to ComponentDeps", we
      kept all uses to be the same old deps, without changing anything by using
      those new setup deps. In several places in InstallPlan it makes sense to
      use all deps, including setup deps. In fact for InstallPlan we should always
      use all deps except in one place: in checking plan validity where we check
      for dependency inconsistencies. That's the one place where we look only at
      "normal" non-setup deps to check that we're using only one version of each
      So for example, with this patch the freeze command now includes setup deps
      in the frozen set. The other case that should change is that failures of
      deps of packages used only for setup scripts should now be handled properly
      because we will look at setup dep edges when looking for things that depend
      on a failed package.
    • Duncan Coutts's avatar
      Remove unused PlanIndex functions · 22e097d0
      Duncan Coutts authored
      Simpler, simpler versions now exist in the InstallPlan module. Those
      ones are simpler because they can use the cached Graph.