FUDCon:Milan 2011 - Ruby SIG meeting

[Darryl L. Pierce]

On Thu, Sep 22, 2011 at 01:52:38PM -0400, Hugh Brock wrote:
> > I'm talking about completely separating Ruby gems from Fedora. So, for
> > example, installing Fedora XX won't require rubygem-rails yy.xx.
> > Insteadl, _all_ Ruby gems would be kept in a separate, optional yum
> > repository. Then you could maintain the gems separately.
> > 
> > So if you're app requires Rails 2.3.11 and farkle 3.1, even though those
> > aren't the latest, then you could install them without having to hunt
> > down, grab and install the RPMs (and then do the same for all
> > dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11,
> > 3.0.0, 3.1.0, etc. and all dependent versions available.
> 
> This is probably going to give fedora packagers massive heartburn, but
> I think Darryl is on the right track here.
> 
> To really make this work you also need a way to install multiple
> stacks of gems on the same machine. So I need for example to be able
> to have two different Rails apps installed, each of which may depend
> on different and conflicting package sets, and have everything work
> and be happy. As horrible as this is from a support standpoint, it is
> the way the Ruby world works, and trying to get away from it is
> swimming upstream...

Kernel packages are already supported this way. Actually RPM will let
you install multiple versions of the same base-named RPM by doing an
install rather than an update.

The big picture we had was to have a package group called "Ruby
Developer" that would install a few things, like define a Yum repo for
the supported Ruby gems repo, install a yum{ex} plugin that would handle
installing the multiple versions of gem (and could be abstracted to handle
the same situation with Python eggs and Java jars), etc.

As for the Ruby gem repo, what we talked about there was a server that
would act as a staging area for moving gems into a supported state. It
would have an application that would regularly scour RubyGems.org for
the latest versions of all gems. Any that it finds that 1) are not
already packaged on the gem server or 2) are not already maintained by a
package maintainer would be downloaded and an attempt to wrap it as an
RPM made. This would let Ruby developers point to it for work without
having to track down the dependencies themselves. (and yes, we realize
this automated system is going to have failures that we can fix as we
go)

The nice thing here is that, if you're going to use a gem that's not
being maintained, it would be one step away from being adopted. The
developer could go to the repo, select the gem RPM and submit it to the
package approval process. The SRPM and SPEC would already exist, so it's
just a matter of tweaking it.

I'm sure there are a lot of edge cases in this that need to be
addressed. But the overall goal of getting Ruby gems into a state where
Ruby developers on Fedora can consume them is attainable along lines
like this.

> /me ducks large rocks

Hit them back with a halibut!

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20110922/c9354f2b/attachment.bin