Rails 3.0.3 RPMs for F15

Mohammed Morsi mmorsi at redhat.com
Fri Jan 14 14:54:47 UTC 2011

  On 01/14/2011 04:08 AM, Vít Ondruch wrote:
> Dne 14.1.2011 09:50, Mohammed Morsi napsal(a):
>>     On 01/14/2011 02:58 AM, Mohammed Morsi wrote:
>>>      On 01/12/2011 11:29 AM, Vít Ondruch wrote:
>>>> Are we really going to replace Rails 2.x with Rails 3.0.x or should they
>>>> live side by side? Your specs shows the later and I am also fan of the
>>>> later. However, I am not sure everybody else will be happy with this
>>>> step. Was it discussed before? Sorry, I am not following Fedora Rails
>>>> development that long :/
>>> Yea, we went back and forth on this a few times and I believe the
>>> general consensus was to do the update.
>>>> Dne 11.1.2011 19:11, Mohammed Morsi napsal(a):
>>>>>        The Rails 3.0.3 RPMs for Fedora are just about ready to go. Please
>>>>> look at and review the Specs and SRPMs below:
>>>>> Rails:
>>>>> http://mo.morsi.org/files/rpms/rubygem-rails-3.0.3-1.fc14.src.rpm
>>>>> http://mo.morsi.org/files/rpms/rubygem-rails.spec
>>>> There are missing dependency on railties and bundler, where there is
>>>> enforced reference to rake which should not be necessary according to
>>>> rails gemspec: https://github.com/rails/rails/blob/v3.0.3/rails.gemspec
>>>> https://github.com/rails/rails/blob/v3.0.3/rails.gemspec
>>> Good catch on these, I probably already had them installed when I was
>>> building these rpms. I'll add them to a revised set of rpms which I'll
>>> send out soon. I also noticed a missing activemodel dependency for
>>> activeresource (which isn't a big deal since activemodel 3.0.3 has been
>>> submitted to Fedora) as well as a rack ~>    1.2.1 dependency for
>>> actionpack. The latter is a little more concerning as the current Rack
>>> version in Fedora is 1.1.0 and if Rails 3 doesn't play well with this
>>> (we can try patching rails itself) we may have to update that as well.
>>>       -Mo
> Well I did not have chance to go through all the specs, so it was the
> first thing I spotted ;)
>>> _______________________________________________
>>> ruby-sig mailing list
>>> ruby-sig at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>> I just ran the actionpack 3.0.3 test suite against Rack 1.1.0 and
>> everything passed. Also the Rails 3 commit updating the dependency to
>> Rack 1.2.1 seems pretty trivial, the only actual code change is to a test.
>> https://github.com/rails/rails/commit/f3bb185b03e746b52a4035a6df002597d8552e74
>> Of course ideally we'd just update Rack to the latest upstream release
>> (1.2.1) in F15. Filed a request w/ the maintainer (jeroen) to do so.
>>      -Mo
>> _______________________________________________
>> ruby-sig mailing list
>> ruby-sig at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> I have good experience with Rack backward compatibility. Actually the
> Rack API is so simple that it would be surprising if it didn't work :)
> But what prevents us from updating Rack?

We don't own Rack :-)  Nor are either of us co-maintainers. Its really 
up to the owner to push updates to the package. Now that being said, 
there are steps which can be taken if a package goes stale for too long 
after an update request.

> And regarding the required versions, I am sure that Rails are pushing as
> new gems as they can, which is not always what we need for Fedora. It
> seems to me that the same case is with Arel. Rails are requesting Arel
> 2, but the Arel 1 should be compatible IMO (I did not tested it though).
> Vit
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Good to know. I had the feeling that this was the case when I sent out 
my original list of rubygem packages that would need to be updated to 
work with Rails 3. Do you know of any way to test this short of running 
each package's test suite against the older versions of the deps? 
Perhaps we can develop some more cross-gem compatibility test cases at 
some point. This all will get trickier as more projects use bundler as 
we'll have to patch them to remove the specific versioned dependencies.


More information about the ruby-sig mailing list