Are you sure? I don't know that it's possible for a gem to have a dependency on multiple versions of a single gem. The only way I can think of doing something like that would be to bake in something like rbenv/RVM and switch environments. Here's what I see on my machine:
$ gem dependency chef
Gem chef-11.8.2
chef-zero (>= 1.6.2, ~> 1.6)
diff-lcs (>= 1.2.4, ~> 1.2)
erubis (~> 2.7)
highline (>= 1.6.9, ~> 1.6)
json (<= 1.7.7, >= 1.4.4)
mime-types (~> 1.16)
mixlib-authentication (~> 1.3)
mixlib-cli (~> 1.3)
mixlib-config (~> 2.0)
mixlib-log (~> 1.3)
mixlib-shellout (~> 1.2)
net-ssh (~> 2.6)
net-ssh-multi (~> 1.1.0)
ohai (~> 6.0)
pry (~> 0.9)
puma (~> 1.6)
rack (>= 0, development)
rake (>= 0, development)
rdoc (>= 0, development)
rest-client (< 1.7.0, >= 1.0.4)
rspec-core (~> 2.13.0, development)
rspec-expectations (~> 2.13.0, development)
rspec-mocks (~> 2.13.0, development)
rspec_junit_formatter (>= 0, development)
sdoc (>= 0, development)
yajl-ruby (~> 1.1)
Gem chef-zero-1.7.2
hashie (~> 2.0)
json (>= 0)
mixlib-log (~> 1.3)
moneta (< 0.7.0)
rack (>= 0)
rake (>= 0, development)
rspec (>= 0, development)
The lines with multiple version declarations are not requiring different/conflicting versions, they're being very explicit about the dependent versions. For instance:
chef-zero (>= 1.6.2, ~> 1.6) matches 1.6.2 and 1.6.3 but not 1.6.1 or 1.7.0
FPM does a fairly good job of converting Ruby gems to RPMs and chasing down dependencies. It's not perfect but it's been rather useful for our needs.
* On our production systems, we do this for the majority of things that are not part of the core OS.