If you are deploying to production and point your prod servers at this external rubygems-rpm YUM repo, could you also not just lock the version of the rpm so that a yum update does not override your prod deployed version? Keeping binaries for every rubygem that we deem "code safe" in our repo would be a hassle to some degree, but I think far less of an issue than everyone in the world keeping separate yum repos of all the rpms needed for their deploy. Pooling resources would do the world a favor here ;)

Sure, Fedora could ship with a few of these rpms, the ones needed for a base deploy, but even then YUM will know not to remove those gems, but rather to install side-by-side gems when you launch your prod code.

Later on there might be an option for a "fedora-sanctioned" version of rpm that will keep separate gemsets through some magic not yet coded, but that's not what we're talking about now and probably will not need to talk about for a while.

From: "Jeroen van Meeuwen" <kanarip@kanarip.com>
To: ruby-sig@lists.fedoraproject.org
Sent: Sunday, October 2, 2011 11:56:41 AM
Subject: Re: FUDCon:Milan 2011 - Ruby SIG meeting

Darryl L. Pierce wrote:

> On Fri, Sep 23, 2011 at 09:47:32AM +0200, Vít Ondruch wrote:

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


> But it can be told to not do that in certain cases. For example, look at

> how kernels are handled. They're all named "kernel" but yum will do an

> install rather than an upgrade when dropping a new one on the system.


During the initial 'yum install' however, YUM will automatically select the latest version as the best candidate - this has been demonstrated with providing multiple versions of kernel packages in anaconda installations with the "release" and "updates" repository enabled.

We also have to consider the implications of making this an add-on repository. Koji build target tags will have to point to different target tags, so that mashing can pick it up, of which a different configuration would be required to include all versions of all packages, and not just the latest (as is currently the case for the updates repository), not to mention the implications on Bodhi and PackageDB.

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


> Okay, I can see some potential problems there if a native gem has a

> dependency on a library that's only available in the main Fedora repos.

> This would be one of those edge cases I was talking about that would

> need to be addressed. :)


For most gems, compatibility with 1.8.5, 1.8.6, 1.8.7, 1.9.1 and 1.9.3 (supposedly) had not been a problem.

Binary gems, however, obviously need to be rebuild for various versions of Ruby. Luckily, Ruby has a search path that could be used for exactly this purpose. However, the packaging overhead would be significant - having to rebuild a binary gem package for "all" Ruby versions has limited sustainability. I have always looked for ways to have this building-against-multiple-versions be done automatically. I don't think it's completely infeasible, and can be accomplished with a plugin to Koji.

Kind regards,

-- kanarip

ruby-sig mailing list