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 _______________________________________________ ruby-sig mailing list ruby-sig(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

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] 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?