Updating bundler in EPEL6

[Mo Morsi]

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

[Vít Ondruch]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

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

[Vít Ondruch]

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

[1] https://fedoraproject.org/wiki/Packaging:Old_Ruby

[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-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