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

Chad Fowler chad at chadfowler.com
Mon Oct 11 07:39:28 EDT 2004

On 11-Oct-04, at 3:58 AM, Omar Kilani wrote:

> Aredridel wrote:
>> Yeah, I bet! Conferences are always fun like that... better once 
>> there ;-)
>> 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.
> I've been working on this for my distribution, and the result is here:
> http://minbar.tinysofa.org/pub/tinysofa/extras/server-2.0/srpms.extras/
> See ruby-gems-*.src.rpm.
> I basically did this to get Rails to work, but now I have a "standard" 
> RPM spec file for doing GEM -> RPM builds. I'm working on a gem2rpm 
> type  script as well... but for the mean time, what the above gives 
> you is a working RPM set of rubygems and all necessary gems for the 
> rails gem to work. It installs these files as gems, with the benefits 
> of having rpm handling all the dependencies and so forth. So doing a 
> rpm install of the ruby-gems-blah rpm adds blah to the gems repository 
> (you can see it when doing a 'gem list', etc) and doing a rpm erase 
> removes it from the gems repository. I use APT in my distribution, so 
> it works very nicely for gem dependencies.
> Please note that almost none of the Ruby libraries out there respect 
> the DESTDIR environment variable when doing install.rb etc, so I have 
> a tonne of patches against a lot of these libraries to make them build 
> properly. I build all my rpms in a clean chroot as a non-root user, so 
> the SRPMS are created with that goal in mind.
> rubygems itself is broken in the DESTDIR regard, so I've got a couple 
> of fixes in place for that. There's one more issue of require_gem 
> looking into the DESTDIR instead of the Gems repository with my 
> changes, so I'm relying on RPM Requires and forcing gem install for 
> gems that have requirements. I'll get to this in the next release of 
> the SRPM.
> I've also had to rebuild the rails gem as it had a couple of hardcoded 
> references to /usr/local/bin/ruby, which I've changed to /usr/bin/env 
> ruby. I really wanted to use the gemspec to do this, and rebuild each 
> gem from scratch in the SRPM, but for some reason the rails tgz has 
> different content to the rails gem, so I went with the "gem as source" 
> option for now.
> Anyway... I'm really excited about Ruby and Rails and everything that 
> entails, and thought it would be rather interesting to support it "out 
> of the box" in my distribution, so hopefully I'll keep up the RPM 
> integration effort. :)
> I hope this is helpful to someone... :)

Thanks for the long and detailed note.  As I said previously in this 
thread, we plan to fix our rather naive install.rb, so some of your 
pains should go away with the next rubygems release.  I'd love to see 
your gem2rpm script when you get that sorted out.

It's interesting that you chose to actually `gem install` as part of 
the rpm install.  This was the  way at least a couple of us were 
leaning when we initially considered native packaging system 
integration.  So, you can do both rpm query and gem list and see the 
installed lib?  The only weird thing I guess would be that you could 
then do "gem uninstall libname" and cause your rpm database to become 
inconsistent with reality.


More information about the Rubygems-developers mailing list