On Dec 31, 2009, at 09:00, Luis Lavena wrote:
Let's take the example: thin.
http://gemcutter.org/gems/thin/versions/1.2.5
Version 1.2.5 depends on:
daemons >= 1.0.9
eventmachine >= 0.12.6
rack >= 1.0.0
daemons 1.0.10 suffices the first dependency:
http://gemcutter.org/gems/daemons/versions/1.0.10
eventmachine 0.12.10 does the second:
http://gemcutter.org/gems/eventmachine/versions/0.12.10
rack 1.0.1 completes the chain:
http://gemcutter.org/gems/rack/versions/1.0.1
none of thin dependencies depends on other libraries at runtime. so
clearly is:
thin:
- daemons
- eventmachine
- rack
With that scenario, the order gems are supposed to be installed are:
eventmachine, daemons, rack, thin
BUT, for some reason, RubyGems does this:
eventmachine, daemons, thin, rack
And when reaches thin, it fails due missing rack.
DependencyList isn't smart enough to know about runtime vs.
development, and there's a circular dependency between rack and thin,
so the order ends up wrong. I'm working on it.
_______________________________________________
Rubygems-developers mailing list
http://rubyforge.org/projects/rubygems
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
