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
Dne 27.3.2014 21:49, Mo Morsi napsal(a):
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)
There is one issue with Bundler in Rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=1054793
But that should not be of concern for EPEL ;)
Vít
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@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?
-Mo
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6696082 [2] https://admin.fedoraproject.org/updates/rubygem-bundler-1.5.2-2.el6 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=6696062
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]
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
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-ht...
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
ruby-sig@lists.fedoraproject.org
-
Mo Morsi -
Vít Ondruch