Bug 87304

Summary:	Have gems.eclass try MY_P over P if set
Product:	Gentoo Linux	Reporter:	Caleb Tennis (RETIRED) <caleb>
Component:	[OLD] Development	Assignee:	Rob Cakebread (RETIRED) <pythonhead>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ruby
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Caleb Tennis (RETIRED) gentoo-dev

2005-03-30 09:53:13 UTC

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:

Comment 1 Rob Cakebread (RETIRED) gentoo-dev

2005-03-30 16:53:19 UTC

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