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

Aredridel aredridel at gmail.com
Sun Oct 10 20:34:07 EDT 2004

> > 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.

That's the most bizarre part: Rails is not a library in the usual
sense. It's a template, a framework -- It's essentially its own
development environment. It makes packaging rather difficult, since
there's not much precedent for it, except C example code which you
just cp -a into your project.
> > 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.

Good, good -- I heartily look forward to it, though in the interest of
clean dependencies, I hate to see libraries require parsing in the
RubyGems code to even operate. It strikes me as ungainly at best.

> > 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.

Partly, the problem is reduction of runtime dependencies. PLD (and
most other distros) strive for minimal sets of required dependencies,
since it's one of the fastest paths to solid, maintainable packaging:
modular as much as possible, but reduce the dependencies too. It's a
really tough balancing act, sometimes.

> > 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
> it?

It requires gems anyway, just avoids the gem command. And without
being able to package the gems library up neatly (yet, I'm mostly
short on time, but I also keep waiting for RubyGems to stabilize so I
won't have to redo work when it changes again), I can't run Rails.

My sysadmin policy for all production servers is that things Do Not
Get Installed Without RPM. The central database is neccesary for me to
keep track of the huge number of dependencies I deal with daily; I
won't even be using RPA, either, nor do I just un-tar stuff and go,
because of that. I just have to have the dependencies managed, because
it's a pain when things break and you don't notice. It's nice for that
to be infrequent.

> > 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.

Please. And encourage people to not depend on RubyGems as much as
possible. One less dependency is a Good Thing, especially since
package management isn't much related to most library tasks.

> > 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.

I hope so. It's a bit thorny -- and may drive people from Ruby if done wrong.

> > 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
> hand-tweaked.

It's an option. The biggest problem is ideological: RPM mandates
"pristine source" -- use the author's original, and apply patches at
build time. Unless the gem is canonical, it won't fly as the original
source, unless you can get the canonical version out.

> 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.

So far, Rails is the biggest pain, but usually it's just removing
require 'rubygems', moving require_gem to require, and then making
sure the libraries end up in the location the FHS says is the right


More information about the Rubygems-developers mailing list