Updating bundler in EPEL6

[Mo Morsi]

On 04/02/2014 03:44 AM, Vít Ondruch wrote:
> Dne 1.4.2014 16:36, Mo Morsi napsal(a):
>> On 03/27/2014 04:49 PM, Mo Morsi wrote:
>>> Greetings, there are a couple of bugs [1] [2] filed against the outdated
>>> version of rubygem-bundler in EPEL.
>>>
>>> Looking at the bundler changelog [3], I do not see any noticeable
>>> regressions / deprecations since the version we currently ship via el6
>>> (1.1.4) so this update should be fine w/ the EPEL update policy [4].
>>>
>>> I've updated my local spec to the version in rawhide (1.5.2) and have
>>> run a working scratch build against the el6-candidate [5].
>>>
>>> Are there any objections to proceeding with this? If not I'll run the
>>> update sometime next week.
>>>
>>> Take care,
>>>   -Mo
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=908061
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1078539
>>> [3] https://github.com/bundler/bundler/blob/master/CHANGELOG.md
>>> [4] https://fedoraproject.org/wiki/EPEL_Updates_Policy
>>> [5] http://koji.fedoraproject.org/koji/taskinfo?taskID=6680738
>> Updated bundler, ran the build [1], and submitted it [2]

Push is a bit delayed due to a missing dep which also had to be built
for epel (net-http-persistent)

https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1086/rubygem-net-http-persistent-2.9.4-2.el6

That should be ready soon after which I'll push the updates.


>>
>> Had to downgrade ruby dep to 1.8 as that is what is available in the
>> build environment. Previous build (pre-update) was not working [3]
>>
>> This introduces an interesting situation, while we can relax the
>> 'Requires: ruby(abi)' version in the spec, only the older version of the
>> ruby library defines this macro, so ruby 1.8 will be pulled in
>> regardless. And it can't be changed to 'ruby(release)' as the older ruby
>> does not define this macro.
>>
>> Would be nice to be able to update this so that if admins get a newer
>> ruby rpm from another source, they can just use that in lieu of also
>> pulling in ruby 1.8 to satisfy this dep. Any thoughts on the feasibility
>> of this? Perhaps the newer ruby macros can also define 'abi' for
>> compatibility purposes? Or something else all together?
> You are speaking about EPEL, where you effectively cannot change
> anything. In Fedora, i'd say we are well past behind this point.
> Moreover, changing Ruby for Ruby from another source, you are asking for
> troubles. This might work for Bundler, but will not work for gems with
> binary extensions.
>
> Also, please note that the guidelines [1] were always very explicit
> about ruby(abi) version, there was never allowed something like relaxing
> the version. You were always supposed to R: ruby(abi) = 1.8.
>
> But may be I just don't cope your idea :)
>
>
> Vít
>
>

Hrm, suppose the crux of the suggestion was to change the current
guidelines to permit relaxing the ruby abi in these types of
environments (eg EPEL6, etc). The idea being to allow for a bit more
flexibility to be able to use updated components in these legacy
environments (if desired, the old being completely compatible).

Not a high priority, things should work as is, albeit perhaps w/ a few
extra packages installed, so no worries either way.

  -Mo