Dne 22.9.2011 20:09, Darryl L. Pierce napsal(a):
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.

You don't need more repositories. One repository can contain package in several versions as far as I know, but YUM is going to install the newest one. RPM allows to install several versions of single package on single computer, but you have to avoid conflicts while you are preparing the package. That works for plain Ruby gems, but it fails with binary gems. See the packaging guidelines.

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

While I like the automated idea, it aims too high IMO. For us, it would be sufficient to keep the previous versions of packages in the repository. That's it. It might not contain every Rails version, or every gem version you can think about, but it will contain just valid packages, the packages somebody took care about.

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!

ruby-sig mailing list