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