[Rubygems-developers] Re: [ANN] dev-utils v1.0

Chad Fowler chad at chadfowler.com
Sun Oct 10 10:50:32 EDT 2004

On 08-Oct-04, at 4:09 PM, Aredridel wrote:

>>> Totally looking forward to the tarball and RPA releases. .. I still
>>> can't get RubyGems to work.
>> What issue are you having?  I saw that you were joining the rubygems
>> developers list.  Can you post your problem there?  I apologize if
>> it's been mentioned and overlooked.  It's been a hectic several weeks
>> leading up to RubyConf.
> Yeah, I bet! Conferences are always fun like that... better once there 
> ;-)

And afterward, better once recovered (which I'm trying to get around to 
today ;)

> I'll admit right now to being an "alternate packager" (I maintain RPMs
> of most of the Ruby stuff in the PLD Linux Distro) -- My biggest
> concern is making some libraries work right. The one I've been working
> on hardest is Rails. Even the tarball version requires rubygems -- not
> the gem command, but the library.

It looks like he includes the rubygems-enabled code, but you don't use 
it unless you have rubygems.  I see rubygems stuff in two places:  
environments/shared_for_gem.rb (which has an alternate non-gem version 
called shared.rb) and in the active record benchmark.rb, but that has a 
conditional load.  So there shouldn't actually be any hard rubygems 
dependencies.  His Rakefiles use the gems lib, because he builds gems 
from them.  I would guess that wouldn't be a problem for you since 
they're build-time only.

> I'm torn between rewriting to not need the RubyGems library (clean
> solution dependency-wise, but ugly in that I maintain an alternate
> version), and packaging RubyGems -- but that's hard, too, since
> install.rb won't install into an alternate root (RPM traditionally
> uses /tmp/packagename/usr/lib/ruby/1.8 for libraries, which RPM then
> relocates into the proper place when installed)

We have that on the TODO list.  As I mentioned on irc, it's just 
something that nobody has asked for until you.  Should be pretty 
straightforward to do, of course.

> The reason this is important is that we're trying to make a pure
> system here -- for Perl, we have a cpan2rpm script, which makes RPM
> spec files that we can then hand-tweak to work exactly right for
> smooth install and uninstall. It calculates dependencies automatically
> and all kinds of stuff.

I would _love_ to see this done for RubyGems, too.  I'd be very happy 
to help in any way I can if you were to run into RubyGems issues in 
making it work.

> For Ruby, I'm still doing it by hand -- though I've talked about
> pulling from RPA when RPA uses pristine sources (which is in the
> plan). The problem of the moment is Rails. It's really hard to get
> installed without Gems, and Gems itself is posing trouble.

I bet DHH would like to hear about your problems getting rails 
installed without gems.  What specifically happens when you try to do 

> The gem command would be nice to offer PLD users as an option, since
> what users want to do with their own systems is up to them, but that's
> secondary in my mind to packaging the libraries well with the native
> tools.

I understand now.  I was wondering why, with a big focus on keeping 
everything "native", you would have even been interested in packaging 
RubyGems for your systems.  Makes sense now.  We just need to give you 
a better installer.

> The other problem I have is just one of consistency. If a few
> libraries are gems in PLD, and the rest are not (since setup.rb does
> so nicely from tarball, making RPMs is really simple and I see no
> reason to add a gem dependency...), the -rubygems becomes a little
> scary. My mind says that running a ruby script shouldn't take any more
> than "ruby file.rb", and having to set RUBYOPTS is kinda kludgy, too,
> though PLD could handle it if it really had to.

All of the non-require_gem methods are hacks.  And require_gem is 
suboptimal.  the RUBYOPT thing is the cleanest, least-intrusive way 
we've seen to deal with it so far.  We have some ideas about doing 
"deployments" of gems, which would make them work without anything 
special.   Time will lead to a solution to this problem, I'm sure.

> Basically, I'm looking for the cleanest ways to make RPMs. At the
> moment, Rails is the first thing I've come across with a hard
> dependency on gems. I can see gem versions needing gems, but there's
> usually a tarball too. The problem comes when even the tarball needs
> the gems library....

How much effort do you think it would take to make rubygem2rpm?  My 
slightly dated RPM packaging experience tells me it wouldn't be _too_ 
difficult--especially if you just wanted to get things in shape to be 

Some specifics on the Rails problems you have would be great.  And any 
other issues you have while trying to repackage any gems would be 
greatly appreciated.


More information about the Rubygems-developers mailing list