FUDCon:Milan 2011 - Ruby SIG meeting

[Vít Ondruch]

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
> go)

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
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20110923/33885b63/attachment-0001.html