Some ebuilds may not be named the same as their packages - for example, dev-ruby/redcloth is associated with the package "RedCloth", so it's worked around by using MY_P in the ebuild. The gems.eclass uses $P internally, so it can't handle these particular instances. The current workaround is to simply make the package download the name that gems.eclass is expecting, as rubyforge will let you download non-existant package names. Reproducible: Always Steps to Reproduce:
I fixed gems.eclass and also changed redcloth-3.0.3 to revert to using MY_P. I also added some einfo, since you'll now need to add: require 'rubygems' before being able to: require 'redcloth' No packages in portage require redcloth (at least not in dev-ruby), so I don't think anything will break except user's own code. And heres some notes I wrote about using gems in ebuilds: http://dev.gentoo.org/~pythonhead/ruby/gems.html
