FUDCon:Milan 2011 - Ruby SIG meeting

[Darryl L. Pierce]

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.

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

> >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)
> 
> While I like the automated idea, it aims too high IMO.

Always aim high. :)

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

I think that's insufficient. The goal is to make available all versions
so that someone who has a specific need can fulfill it. Keep n and n-1
just pushes back the problem by one release.

-- 
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/20110923/f1986440/attachment.bin