Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the Apache license #1

Merged
merged 2 commits into from
May 7, 2012
Merged

Add support for the Apache license #1

merged 2 commits into from
May 7, 2012

Conversation

iustin
Copy link
Contributor

@iustin iustin commented Apr 22, 2012

This patch adds the Apache license (http://www.apache.org/licenses/)
as a versioned license. I'm not entirely sure this is correct, since
they do fractional versions (1.1, 2.0) as opposed to the FSF ones
which are integral (2, 3, etc.); so the fact that the version is an
integer doesn't map well.

I've also updated slightly the license parse test, but I'm not sure
that the instructions for running the tests are correct (I don't see
the "license parsers" test being shown when running
./test/dist/build/suite/suite).

iustin added 2 commits April 28, 2012 12:51
This patch adds the Apache license (http://www.apache.org/licenses/)
as a versioned license. Only version 2.0 is added, as the others are
historical and should not be used.

I've also updated slightly the license parse test, but I'm not sure
that the instructions for running the tests are correct (I don't see
the "license parsers" test being shown when running
./test/dist/build/suite/suite).
I've verified that a generated license file is identical to the
original copy at http://www.apache.org/licenses/LICENSE-2.0.txt,
otherwise this is a trivial patch.
@iustin
Copy link
Contributor Author

iustin commented Apr 28, 2012

Uh, I fear the old discussion has been "eaten" by my force push on this branch/pull request…

@kosmikus
Copy link
Contributor

I think I'd still go for [2] and not [2,0]. GPL also has version 3.0, and we represent it using [3]. I just wanted to make clear that version 1.1 could without trouble be represented as [1,1].

@iustin
Copy link
Contributor Author

iustin commented Apr 28, 2012

Sure, I'm not particular to either [2] or [2, 0]. Shall I re-send as [2]?

I can also add one patch on top changing it, whatever works best.

@iustin
Copy link
Contributor Author

iustin commented Apr 28, 2012

I've done some investigation on this. The GPL 3 license says, under "How to Apply These Terms to Your New Programs", the following:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Note the unqualified 3.

On the other hand, Apache says under "APPENDIX: How to apply the Apache License to your work":

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at …

Note the qualified 2.0, and thus my original intention of marking this explicitly as such.

Anyway, I have a patch ready changing this to a plain 2, just let me know which one you prefer.

@kosmikus
Copy link
Contributor

You're making a good point. I'm willing to go with [2,0] then.

@kosmikus
Copy link
Contributor

Your cabal init changes look fine to me. I'm still slightly worried about backwards compatibility issues. @dcoutts ?

@iustin
Copy link
Contributor Author

iustin commented May 7, 2012

Small ping?

If you can explain the backwards compat issues (I didn't understand them), I can look into it. Thanks!

@kosmikus
Copy link
Contributor

kosmikus commented May 7, 2012

I've talked to @dcoutts, and I think the agreement was that there are no backwards compat issues. I'll merge.

kosmikus added a commit that referenced this pull request May 7, 2012
Add support for the Apache license
@kosmikus kosmikus merged commit 39db02e into haskell:master May 7, 2012
@dcoutts
Copy link
Contributor

dcoutts commented May 10, 2012

Yep, I'm happy, code looks fine.

Only question is if we want to allow specifying an unversioned Apache license? We allow unversioned for GPL and LGPL only as a backwards compat thing, because we didn't initially have versioned licenses at all.

Actually, looking at the code I think we could get away with dropping the unversioned GPL and LGPL from the knownLicenses. All it means is you'll get a build warning (and such packages will not be able to be uploaded to hackage).

grayjay added a commit to grayjay/cabal that referenced this pull request Dec 19, 2016
Previously, the solver only checked for cycles after it had already found a
solution. That reduced the number of times that it performed the check in the
common case when there were no cycles. However, when there was a cycle, the
solver could spend a lot of time searching subtrees that already had a cyclic
dependency and therefore could not lead to a solution. This is part of
haskell#3824.

Changes in this commit:
- Store the reverse dependency map on all choice nodes in the search tree, so
  that 'detectCyclesPhase' can access it at every step.
- Check for cycles incrementally at every step. Any new cycle must contain the
  current package, so we just check whether the current package is reachable
  from its neighbors.
- If there is a cycle, we convert the map to a graph and find a strongly
  connected component, as before.
- Instead of using the whole strongly connected component as the conflict set,
  we select one cycle. Smaller conflict sets are better for backjumping.
- The incremental cycle detection automatically fixes a bug where the solver
  filtered out the message about cyclic dependencies when it summarized the full
  log. The bug occurred when the failure message was not immediately after the
  line where the solver chose one of the packages involved in the conflict. See
  haskell#4154.

I tried several approaches before I found something with reasonable performance.
Here is a comparison of runtime and memory usage. I turned off assertions when
building cabal.

Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
GHC 8.0.1

Runtime in seconds:
Packages                    Search tree depth   Trials   master   This PR   haskell#1      haskell#2
yesod                       343                 3        2.00     2.00      2.13    2.02
yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
phooey                      66                  3        3.48     3.54      3.56    3.57
stackage nightly snapshot   6791                1        186      193       357     191

Total memory usage in MB, with '+RTS -s':
Packages                                        Trials   master    This PR   haskell#1     haskell#2
yesod                                           1         189       188       188     198
yesod gi-glib leksah                            1         257       257       263     306
stackage nightly snapshot                       1        1288      1338      1432   12699

haskell#1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
     every step.
haskell#2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
     check for cycles containing the current package at every step.
grayjay added a commit to grayjay/cabal that referenced this pull request Dec 19, 2016
Previously, the solver only checked for cycles after it had already found a
solution. That reduced the number of times that it performed the check in the
common case where there were no cycles. However, when there was a cycle, the
solver could spend a lot of time searching subtrees that already had a cyclic
dependency and therefore could not lead to a solution. This is part of
haskell#3824.

Changes in this commit:
- Store the reverse dependency map on all choice nodes in the search tree, so
  that 'detectCyclesPhase' can access it at every step.
- Check for cycles incrementally at every step. Any new cycle must contain the
  current package, so we just check whether the current package is reachable
  from its neighbors.
- If there is a cycle, we convert the map to a graph and find a strongly
  connected component, as before.
- Instead of using the whole strongly connected component as the conflict set,
  we select one cycle. Smaller conflict sets are better for backjumping.
- The incremental cycle detection automatically fixes a bug where the solver
  filtered out the message about cyclic dependencies when it summarized the full
  log. The bug occurred when the failure message was not immediately after the
  line where the solver chose one of the packages involved in the conflict. See
  haskell#4154.

I tried several approaches and compared performance when solving for
packages with different numbers of dependencies. Here are the results. None of
these runs involved any cycles, so they should have only tested the overhead of
cycle checking. I turned off assertions when building cabal.

Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
GHC 8.0.1

Runtime in seconds:
Packages                    Search tree depth   Trials   master   This PR   haskell#1      haskell#2
yesod                       343                 3        2.00     2.00      2.13    2.02
yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
phooey                      66                  3        3.48     3.54      3.56    3.57
Stackage nightly snapshot   6791                1        186      193       357     191

Total memory usage in MB, with '+RTS -s':
Packages                                        Trials   master    This PR   haskell#1     haskell#2
yesod                                           1         189       188       188     198
yesod gi-glib leksah                            1         257       257       263     306
Stackage nightly snapshot                       1        1288      1338      1432   12699

haskell#1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
     every step.
haskell#2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
     check for cycles containing the current package at every step.
ezyang pushed a commit that referenced this pull request Dec 27, 2016
Previously, the solver only checked for cycles after it had already found a
solution. That reduced the number of times that it performed the check in the
common case where there were no cycles. However, when there was a cycle, the
solver could spend a lot of time searching subtrees that already had a cyclic
dependency and therefore could not lead to a solution. This is part of
#3824.

Changes in this commit:
- Store the reverse dependency map on all choice nodes in the search tree, so
  that 'detectCyclesPhase' can access it at every step.
- Check for cycles incrementally at every step. Any new cycle must contain the
  current package, so we just check whether the current package is reachable
  from its neighbors.
- If there is a cycle, we convert the map to a graph and find a strongly
  connected component, as before.
- Instead of using the whole strongly connected component as the conflict set,
  we select one cycle. Smaller conflict sets are better for backjumping.
- The incremental cycle detection automatically fixes a bug where the solver
  filtered out the message about cyclic dependencies when it summarized the full
  log. The bug occurred when the failure message was not immediately after the
  line where the solver chose one of the packages involved in the conflict. See
  #4154.

I tried several approaches and compared performance when solving for
packages with different numbers of dependencies. Here are the results. None of
these runs involved any cycles, so they should have only tested the overhead of
cycle checking. I turned off assertions when building cabal.

Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
GHC 8.0.1

Runtime in seconds:
Packages                    Search tree depth   Trials   master   This PR   #1      #2
yesod                       343                 3        2.00     2.00      2.13    2.02
yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
phooey                      66                  3        3.48     3.54      3.56    3.57
Stackage nightly snapshot   6791                1        186      193       357     191

Total memory usage in MB, with '+RTS -s':
Packages                                        Trials   master    This PR   #1     #2
yesod                                           1         189       188       188     198
yesod gi-glib leksah                            1         257       257       263     306
Stackage nightly snapshot                       1        1288      1338      1432   12699

#1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
     every step.
#2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
     check for cycles containing the current package at every step.
@BenBals BenBals mentioned this pull request Aug 7, 2019
emilypi added a commit to emilypi/cabal that referenced this pull request Feb 1, 2021
* Add TESTING.md to `cabal-install` project directory.
* Add CONTRIBUTING.md entry for `cabal-install` testing instructions
andreasabel pushed a commit that referenced this pull request Jan 21, 2022
Also: Fix color formatting when PAGER is 'less'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants