Why upper bound version numbers?
Jeremy .
voldermort at hotmail.com
Thu Jun 9 09:22:23 UTC 2016
Versions of package dependencies can be categorised into 5 sets:
D1) Versions which the maintainer has tested and found to work
D2) Versions which the maintainer has not tested but expects to work
D3) Versions which the maintainer has tested and found to not work
D4) Versions which the maintainer has not tested but expects to not work
D5) Everything else
Cabal, however, only knows of 3 sets:
C1) Versions which satisfy build-depends
C2) Versions which satisfy build-depends with --allow-newer
C3) Everything else
The problem arises from the fact that the D sets to not map well onto the C sets, even after combining D1&D2 and D3&D4. Perhaps this could be solved with a new .cabal property, breaks-with. The solver will then prefer packages in this order:
1) Versions that satisfy build-depends
2) Versions that are not in breaks-with, unless a flag such as --strict-build-depends is applied
This may also lead to clearer build-depends, as instead of multiple ranges with gaps to skip know broken versions, build-depends can list a single range, and breaks-with can list the bad versions.
More information about the ghc-devs
mailing list