Cached .gem file - include it or not

[Bohuslav Kabrda]

----- Original Message -----
> Hi,
> I would like to start discussion, whether packaged rubygems should
> include cached gem file.
> I'm seeing shift from "should exclude cached .gem file" to "must
> exclude
> cached .gem file". I tried to search archive of this mailing list for
> discussion about this, but find none.
> 
> While current guidelines does not address this:
> http://fedoraproject.org/wiki/Packaging:Ruby#RubyGems
> 
> In discussion page:
>    http://fedoraproject.org/wiki/Packaging_talk:Ruby#Cached_.gem_file
> is this text:
> 
>  > The package *should* exclude the cached .gem file in files
>  > section:
>  >   %exclude %{gemdir}/cache/%{gemname}-%{version}.gem
>  >Since the gem is installed using RPM, it makes no sense to include
>  >the
>  >cached .gem file. This file is used typically with 'gem pristine'
>  >command to restore gem into its original state, but this could be
>  >achieved by equivalent RPM command.
> 
> And in draft:
>    http://fedoraproject.org/wiki/PackagingDrafts/Ruby
> is even:
>    Since the Gem is installed using RPM, you *must* exclude the .gem
>    file.
> 
> And this is even what is in current fedora-review(1) as in its output
> is:
> [x]: MUST Gem package must exclude cached Gem.
> 
> I do not understand why it is MUST item. And anyway, why it could not
> be
> present.
> I would like to have cached gem in final package. I will tell you
> why.
> I have several collegues, which develop application for Fedora, but
> they
> develop on MacOS.
> Usually they download rubygems from rubygems.org. But sometimes
> Fedora
> version of rubygem has patch applied.
> In such case when we do:
> 
> %prep
> gem unpack %{SOURCE0}
> %setup -q -D -T -n  %{gem_name}-%{version}
> gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
> %patch0 -p1
> 
> %build
> ...
> gem build %{gem_name}.gemspec
> 
> the resulting gem file is different (compared to rubygem.org
> version).
> If cached gem file is present in package, they can easily extract it
> and
> use this one - because sometimes the behaviour is different (compared
> to
> rubygem.org version).

Do you have an example of a behaviour change that would actually break anything? I'm quite sure we don't apply any wild API breaking patches, mostly just CVE fixes. I know that your argument is what Ruby (or Bundler) folks often say, so I'd like to see where we actually changed anything in a way that would cause problems. (This is _not_ a flamewar starter, I'm really curious if you are referring to a specific case or just talking about a possibility.)

> And if I correctly understood 'gem pristine' - it will not help here
> as
> it will not create .gem file with those security patches.
> 
> So what I would like to see, is to have cached gem present in
> package.
> At list for packages containing patch.
> 
> But since people have tendency to forget ("Oh, security problem. Lets
> add patch." days/month later: "You forgot to add cached .gem."
> "Sorry")
> - I would suggest to include cached gem always (i.e. MUST item). But
> I
> understood that sometimes it can be very hard to repackage gem, as it
> can be old and may miss some required metadata, so I would say it
> SHOULD
> include cached gem.
> 
> Opinions?
> --
> Miroslav Suchy
> Red Hat Systems Management Engineering
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

-- 
Regards,
Bohuslav "Slavek" Kabrda.