This is dealt with in the FAQ - but the short answer is that Gemcutter mirrors all gems from RubyForge. If you want to push directly to Gemcutter instead of letting Gemcutter mirror it, you need to go through a migration process to verify you are the owner.
So no, you can't just upload a gem titled "rails" to Gemcutter and have it override the Rails team's gems.
Is there any reason you can't post a gem called why-hpricot to RubyForge and have it override GitHub?
This doesn't seem like a new problem to me. If this concerns you, just edit the sources list of your .gemrc file manually and make sure RubyForge is at the top and Gemutter is at the bottom.
That's a very valid point since for most people gems.github.com comes after RubyForge in the source list. Oy... makes me think running 'gem install' without --source is just a bad idea.
We added code at least a year ago to prevent people from building gems with the name of a gem already hosted on rubyforge. That being said, the rubygem library itself really needs some type of namespacing solution to solve the problem once and for all instead of requiring gem hosts to implement hacks like we did. Fortunately, I've heard rumblings that they may be working on something.
Heh, if you think that is wild and crazy, a long time ago the 'script/plugin' command in Rails pulled its' svn sources from a public wiki that anyone could edit.
I enjoy how RubyForge is run by RubyCentral. I don't know if this is the long term replacement for gem hosting, but it would be good if there were some sort of (hopefully transparent) organization behind the service (beyond a temporary alliance of companies) to guarantee funding.
9 comments
[ 2.6 ms ] story [ 31.0 ms ] threadSo no, you can't just upload a gem titled "rails" to Gemcutter and have it override the Rails team's gems.
This doesn't seem like a new problem to me. If this concerns you, just edit the sources list of your .gemrc file manually and make sure RubyForge is at the top and Gemutter is at the bottom.
More details on what I want to do: http://rubyforge.org/pipermail/rubygems-developers/2009-Augu...
The short answer is: be explicit with what source you're looking at, and start looking into gem signing/certs since it's the way we can trust gems.
More info here: http://litanyagainstfear.com/blog/2009/10/09/on-gem-forking/
*Edit: Looks like rufo already cleared this up...thanks man!