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 rocksHit them back with a halibut!
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig