
First of all, I don't think libraries@ is the right place for this discussion.
You should probably move it to -cafe until you have a concrete proposal
for libraries changes.
To answer your question: you're interpreting the results wrong.
If cabal found a way to build the package with these constraints and the
build itself failed, that would be an argument for restricting bounds.
In this case cabal simply can't find a suitable install plan, which
means that *your* constraints are incompatible. That *probably* means
(although it's easy to come up with a contrived counterexample) that
dependencies can be made a bit tighter, but it's not a maintainer's task
to analyse compatibility of various packages — that's what cabal is for.
Maintainer only specifies constraint within which the package is
supposed to build. The only way such constraints can be proven wrong is
showing a build within the constraints which fails.
Roman
* Bram Neijt
Ok, so I had my first go at this, but it seems all the things I try will fail. My approach was simple: take a single dependency and change ">=" into "==" for that single dependency, then try to build. Do that for every dependency in the cabal file.
Turns out, none of the things I tries would work. Here is a concrete example: mkdir test cd test snap init #Edit the test.cabal file and change bytestring >= 0.9.1 to bytestring == 0.9.1 cabal fetch .
This fails, telling me: $ cabal fetch . Resolving dependencies... cabal: Could not resolve dependencies: trying: test-0.1 (user goal) next goal: xmlhtml (dependency of test-0.1) rejecting: xmlhtml-0.2.0.3/installed-4c6... (conflict: xmlhtml => bytestring==0.10.0.1/installed-7e2..., test => bytestring==0.9.1 && <0.11) trying: xmlhtml-0.2.1 trying: unordered-containers-0.2.3.0/installed-7fe... (dependency of xmlhtml-0.2.1) next goal: hashable (dependency of unordered-containers-0.2.3.0/installed-7fe...) rejecting: hashable-1.2.0.2/installed-bbd... (conflict: unordered-containers => hashable==1.1.2.5/installed-d93...) rejecting: hashable-1.1.2.5/installed-d93... (conflict: hashable => bytestring==0.10.0.1/installed-7e2..., test => bytestring==0.9.1 && <0.11) rejecting: hashable-1.2.0.10, 1.2.0.9, 1.2.0.8, 1.2.0.7, 1.2.0.6, 1.2.0.5, 1.2.0.4, 1.2.0.3, 1.2.0.2, 1.2.0.1, 1.2.0.0, 1.1.2.5, 1.1.2.4, 1.1.2.3, 1.1.2.2, 1.1.2.1, 1.1.2.0, 1.1.1.0, 1.1.0.0, 1.0.1.1, 1.0.1.0, 1.0.0 (conflict: unordered-containers => hashable==1.1.2.5/installed-d93...)
Am I donig something wrong, or does this just mean that the bytstring dependency should be fixed to something above 0.9.1?
Greetings,
Bram
On Wed, Jun 12, 2013 at 9:29 AM, Erik Hesselink
wrote: On Wed, Jun 12, 2013 at 12:16 AM, Roman Cheplyaka
wrote: * Roman Cheplyaka
[2013-06-12 01:10:56+0300] * Roman Cheplyaka
[2013-06-12 01:05:29+0300] * Bram Neijt
[2013-06-11 23:15:39+0200] Hi all,
I think it would be interesting to test build a package with the "latest" and "oldest" allowed dependencies, to see if the dependency boundaries hold. For example, build the text[1] package with version 0.2 of test-framework-hunit (oldest allowed according to .cabal file) to see if that is still works.
Does anybody know of previous work on that? Does anybody have pointers on how to build with a specific version set? What is the easiest way to parse the dependencies in the cabal file, API pointers are also very much appreciated :)
I believe Bram Schuur (CC'd) worked on this during OdHac.
Trying his another email...
Still no luck. This is his github account, maybe try to reach him there: https://github.com/craffit
I believe this address still works.
Regards,
Erik
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries