OpenWrap/openwrap

OpenWrap hangs while or after resolving dependencies.

Opened this issue · 1 comments

Using master of openwrap, I have a package that seems to give some problems while resolving dependencies.

The package I'm trying to build has a dependency on package A, on package B, and a couple of others.

Something like this:
depends: packageA >= 2.0 < 3.0
depends: packageB >= 2.1 < 3.0

On the package repository, we have following versions:
packageA: 2.0.0, 2.1.0, 2.1.1
packageB: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5

packageB itself depends on package A with the following rule:
depends: packageA >= 2.0 < 3.0

The following happens with update-wrap:

  • after the command, i get "updating project packages..." which takes some time......
  • then it prints the lines with the dependencies added "project repository: .... added"
  • then it seems to hang and use more and more memory

It fetches version 2.1.5 of packageB, but version 2.0.0 of packageA. I attached the debugger while it was hanging, and paused it. The debugger stopped in the code in the class LoggingPackageVisitor, method WriteDebug. There are two lists of packages: SuccessfulPackages and IncompatiblePackages. The list SuccesfulPackages seemed normal: 20 entries and packages that make sense. Among those is packageA with version 2.0.0 (which actually fulfills the requirements). The list IncompatiblePackages does not make sense however. At the time i checked it, the list contains 7324218 entries, that all refer to the same package: packageA version 2.1.1. I don't understand why the package ends up in the incompatible list, and I don't get why the same package would be added several times in that list.

So, after a while, I just interrupt openwrap. All required packages have been added in the "wraps"-folder. Even though it didn't fetch 2.1.1 of packageA, the packages that it did fetch do follow the requirements.

PS. Now I noticed during debugging that I specified the version range incorrectly... I forgot the add the "and" keyword in between the version constraints.... but that shouldn't cause the above problem...?

It shouldn't cause the problem but yea the clause is wrong. You can replace it with ~> 2.1 too.

That said it may be a problem with the resolver and some equality going bonkers there. Will have a look when am back on the computer.

Sebastien Lambla

On 16 Jun 2012, at 13:57, "Ruben Vandeginste" reply@reply.github.com wrote:

Using master of openwrap, I have a package that seems to give some problems while resolving dependencies.

The package I'm trying to build has a dependency on package A, on package B, and a couple of others.

Something like this:
depends: packageA >= 2.0 < 3.0
depends: packageB >= 2.1 < 3.0

On the package repository, we have following versions:
packageA: 2.0.0, 2.1.0, 2.1.1
packageB: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5

packageB itself depends on package A with the following rule:
depends: packageA >= 2.0 < 3.0

The following happens with update-wrap:

  • after the command, i get "updating project packages..." which takes some time......
  • then it prints the lines with the dependencies added "project repository: .... added"
  • then it seems to hang and use more and more memory

It fetches version 2.1.5 of packageB, but version 2.0.0 of packageA. I attached the debugger while it was hanging, and paused it. The debugger stopped in the code in the class LoggingPackageVisitor, method WriteDebug. There are two lists of packages: SuccessfulPackages and IncompatiblePackages. The list SuccesfulPackages seemed normal: 20 entries and packages that make sense. Among those is packageA with version 2.0.0 (which actually fulfills the requirements). The list IncompatiblePackages does not make sense however. At the time i checked it, the list contains 7324218 entries, that all refer to the same package: packageA version 2.1.1. I don't understand why the package ends up in the incompatible list, and I don't get why the same package would be added several times in that list.

So, after a while, I just interrupt openwrap. All required packages have been added in the "wraps"-folder. Even though it didn't fetch 2.1.1 of packageA, the packages that it did fetch do follow the requirements.

PS. Now I noticed during debugging that I specified the version range incorrectly... I forgot the add the "and" keyword in between the version constraints.... but that shouldn't cause the above problem...?


Reply to this email directly or view it on GitHub:
#336