RPM - rubygem-rails 1:3.0.5-2.fc15 - includes changes from Rails 3.0.8

[Ivan Necas]

Hello,

While working on Katello, I've encountered a strange problem.

We run against Rails 3.0.5 and in development, we use gem packages from 
'http://repos.fedorapeople.org/repos/katello/gems/'.

Currently, we were reported a bug while testing in fedora 14 (and it 
fails in 15 as well) [1]. This bug however didn't appear in the 
development.

After some investigation, I've found out, that the error was caused by 
the change in rails officially released in v 3.0.8 [2]. But we have this 
change included in RPM for rails version 3.0.5.

Do we have to count on this kind of version differences between Gems and 
RPMs, or there was some problem in packaging?

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=727627#c2
[2] - 
https://github.com/rails/rails/commit/53a2c0baf2b128dd4808eca313256f6f4bb...

Thanks
-- Ivan

[Lukas Zapletal]

On 08/17/2011 12:07 PM, Ivan Nečas wrote:
>  Do we have to count on this kind of version differences between Gems
> and
>  RPMs, or there was some problem in packaging? 
I guess we call this "backporting" :-)

If you check the SRPM, you will find there is the patch you are 
referring to. The thing is - we (or ruby-sig in this case) backport 
important (security related etc) fixes in the released versions. In this 
case its 3.0.5.

It is not possible to upgrade to 3.0.8 because Fedora 15 is considered 
as "stable". We are not rolling Gentoo :-) The only way to fix a 
particular problem is to provide a patch file in the SRPM and bump the 
epoch number (number three in this case). The gold rule is not to modify 
the source tarball. For more info see Fedora Packaging Guidelines.

Do this (having yum-utils installed):

$ yumdownloader --source rubygem-activesupport

Unpack the SRPM (or install it) and find this file:

$ md5sum cve-2011-2197-fix.patch
883d8eac854ded578f4d3f3e371fedc4  cve-2011-2197-fix.patch

Here we go...

http://lists.fedoraproject.org/pipermail/package-announce/2011-June/06209...

It's more Katello problem - you (we) should all develop on the very same 
rubygems as users do have. In this case you use original gem files vs 
gems from RPMs. That is the reason why you see the error in the development.

-- 
Later,
   Lukas "lzap" Zapletal

[Ivan Necas]

On 08/18/2011 09:55 AM, Lukas Zapletal wrote:
>  On 08/17/2011 12:07 PM, Ivan Nečas wrote:
> > Do we have to count on this kind of version differences between Gems and
> > RPMs, or there was some problem in packaging?
>  I guess we call this "backporting" :-)
>
>  If you check the SRPM, you will find there is the patch you are
>  referring to. The thing is - we (or ruby-sig in this case) backport
>  important (security related etc) fixes in the released versions. In this
>  case its 3.0.5.
>
>  It is not possible to upgrade to 3.0.8 because Fedora 15 is considered
>  as "stable". We are not rolling Gentoo :-) The only way to fix a
>  particular problem is to provide a patch file in the SRPM and bump the
>  epoch number (number three in this case). The gold rule is not to modify
>  the source tarball. For more info see Fedora Packaging Guidelines.
>
>  Do this (having yum-utils installed):
>
>  $ yumdownloader --source rubygem-activesupport
>
>  Unpack the SRPM (or install it) and find this file:
>
>  $ md5sum cve-2011-2197-fix.patch
>  883d8eac854ded578f4d3f3e371fedc4  cve-2011-2197-fix.patch
>
>  Here we go...
>
>  http://lists.fedoraproject.org/pipermail/package-announce/2011-June/06209...
>
>  It's more Katello problem - you (we) should all develop on the very same
>  rubygems as users do have. In this case you use original gem files vs
>  gems from RPMs. That is the reason why you see the error in the development.
>  
Thanks for explanation. At least I know where to look when such a 
problem occurs.

Using plain old gems over RPM has some advantages:

1. Some of packages used in development (especially in early stages of 
some functionality) are not packed to RPM yet. It's more effective to 
try it out from gem and if we agree it's worth in, it can be packaged

2. Bundler + RVM makes it much easier to keep the development going. For 
example:
"I've make some experiments using SuperAwesomeGem - check out my branch 
- you will need bundle install before hacking"

3. Some of us use Mac for development - they can't use RPM

What I am trying to say is that pure gems, RVM and bundler are much more 
effective for the development.

Would be possible to take it from the other end, and reflect the changes 
we've made to RPM in ruby gem in our private gem source we use with 
bundler, e.g.: http://repos.fedorapeople.org/repos/katello/gems/.
Ideally with some automated process (I think I shouldn't be hard:)

Question: do RPM for gems differ for different distribution: FC14, 
FC15,  RHEL5, RHEL6?:
If they do, we could similarly keep separated gem source for every 
distribution - this could help us in debugging, if we get report, that 
some distro fails with our app.

What do you think about this apporach?

-- Ivan

[Dmitri Dolguikh]

On 11-08-18 8:13 AM, Ivan Nečas wrote:
>  On 08/18/2011 09:55 AM, Lukas Zapletal wrote:
> > On 08/17/2011 12:07 PM, Ivan Nečas wrote:
> >> Do we have to count on this kind of version differences between Gems and
> >> RPMs, or there was some problem in packaging?
> > I guess we call this "backporting" :-)
> >
> > If you check the SRPM, you will find there is the patch you are
> > referring to. The thing is - we (or ruby-sig in this case) backport
> > important (security related etc) fixes in the released versions. In this
> > case its 3.0.5.
> >
> > It is not possible to upgrade to 3.0.8 because Fedora 15 is considered
> > as "stable". We are not rolling Gentoo :-) The only way to fix a
> > particular problem is to provide a patch file in the SRPM and bump the
> > epoch number (number three in this case). The gold rule is not to modify
> > the source tarball. For more info see Fedora Packaging Guidelines.
> >
> > Do this (having yum-utils installed):
> >
> > $ yumdownloader --source rubygem-activesupport
> >
> > Unpack the SRPM (or install it) and find this file:
> >
> > $ md5sum cve-2011-2197-fix.patch
> > 883d8eac854ded578f4d3f3e371fedc4  cve-2011-2197-fix.patch
> >
> > Here we go...
> >
> > http://lists.fedoraproject.org/pipermail/package-announce/2011-June/06209...
> >
> > It's more Katello problem - you (we) should all develop on the very same
> > rubygems as users do have. In this case you use original gem files vs
> > gems from RPMs. That is the reason why you see the error in the development.
> >
>  Thanks for explanation. At least I know where to look when such a
>  problem occurs.
>
>  Using plain old gems over RPM has some advantages:
>
>  1. Some of packages used in development (especially in early stages of
>  some functionality) are not packed to RPM yet. It's more effective to
>  try it out from gem and if we agree it's worth in, it can be packaged
>
>  2. Bundler + RVM makes it much easier to keep the development going. For
>  example:
>  "I've make some experiments using SuperAwesomeGem - check out my branch
>  - you will need bundle install before hacking"
>
>  3. Some of us use Mac for development - they can't use RPM
>
>  What I am trying to say is that pure gems, RVM and bundler are much more
>  effective for the development.
>
>  Would be possible to take it from the other end, and reflect the changes
>  we've made to RPM in ruby gem in our private gem source we use with
>  bundler, e.g.: http://repos.fedorapeople.org/repos/katello/gems/.
>  Ideally with some automated process (I think I shouldn't be hard:) 
That would
work, and we'll be able to use bundler again! Definitely +1 
from me.
-d

>  Question: do RPM for gems differ for different distribution: FC14,
>  FC15,  RHEL5, RHEL6?:
>  If they do, we could similarly keep separated gem source for every
>  distribution - this could help us in debugging, if we get report, that
>  some distro fails with our app.
>
>  What do you think about this apporach?
>
>  -- Ivan
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Lukas Zapletal]

On 08/18/2011 01:13 PM, Ivan Nečas wrote:
>  Question: do RPM for gems differ for different distribution: FC14,
>  FC15,  RHEL5, RHEL6?:
>  If they do, we could similarly keep separated gem source for every
>  distribution - this could help us in debugging, if we get report, that
>  some distro fails with our app. 
They can be different, yes.

>  What do you think about this apporach? 
I would note that I would prefer patching the upstream. In this case 
asking rubygem author to release 3.0.5.1 patched gem (not sure if 
rubygems support such a convention). And then to use it.

Is it necessary to put that effort in maintaining our own rubygems just 
because few developers (incl. me) do use RVM instead recommended RPM 
gems? I would go for patching upstream if it blocks us (e.g. maybe this 
case - the gettext issue), but for other cases I would recommend to live 
with it.

-- 
Later,
   Lukas "lzap" Zapletal

[Mo Morsi]

On 08/18/2011 07:58 AM, Lukas Zapletal wrote:
>  On 08/18/2011 01:13 PM, Ivan Nečas wrote:
> > Question: do RPM for gems differ for different distribution: FC14,
> > FC15,  RHEL5, RHEL6?:
> > If they do, we could similarly keep separated gem source for every
> > distribution - this could help us in debugging, if we get report, that
> > some distro fails with our app.
>  They can be different, yes.
>
>    >  What do you think about this apporach?
>
>  I would note that I would prefer patching the upstream. In this case
>  asking rubygem author to release 3.0.5.1 patched gem (not sure if
>  rubygems support such a convention). And then to use it.
>  
Well the newer upstream release is the patched version, eg 3.0.8 
contains this fix.

The issue is that we lock the version in any given Fedora release, 
perhaps its time to revisit this policy for certain packages, especially 
as they stabilize more (so long as backwards compatibility is preserved).

   -Mo