gem2rpm fails for google-protobuf

[Hextremist]

This is in fedora 27. Looks like gem2rpm makes some assumptions about the name of the gem file which is not right for this package.

$ cd ~/rpmbuild/SPECS
$ gem fetch google-protobuf
Fetching: google-protobuf-3.5.1.2-x86_64-linux.gem (100%)
Downloaded google-protobuf-3.5.1.2-x86_64-linux
$ gem2rpm google-protobuf-3.5.1.2-x86_64-linux.gem  >~/rpmbuild/SPECS/protobuf.spec
$ rpmbuild -bs ~/rpmbuild/SPECS/protobuf.spec
error: File /home/kjell/rpmbuild/SOURCES/google-protobuf-3.5.1.2.gem: No such file or directory

[voxik]

This is more or less RubyGems which makes some assumption and prefers platform specific version of gem. But for packaging, you should always do gem fetch google-protobug --platform=ruby for gems which provides platform specific versions of gems.

However, not sure if gem2rpm -f google-protobuf > ~/rpmbuild/SPECS/protobuf.spec (the -f param makes gem2rpm to fetch the package) is doing the right thing.

[Hextremist]

Hi,
You are right, and I am sorry :) -f seems to work fine. May I still suggest failing with an error message instead of generating a .spec file that does not work?

[voxik]

I don't target 100% success rate for gem2rpm. But this is definitely interesting case, so I'll keep this ticket open and will see what we can do about it.

[voxik]

Getting back to this after some years, we can detect platform of the gem, which should be converted. Trying to output @spec.platform at this place:

gem2rpm/lib/gem2rpm/context.rb

Line 17 in 783d0df

@spec = Gem2Rpm::Specification.new(@package.spec)

The result for prebuilt gem is

#<Gem::Platform:0x00007f5a9038d960 @cpu="x86_64", @os="linux", @version=nil>

while for "source" version it is just:

"ruby"

But what to do with this information?

Of course gem2rpm can fail for prebuilt gems. But then somebody might want do do that, because it is not prohibited, just convention of some distributions. That would need additional flag to force this behavior and some customizations in template.

I think that would be additional complexity for not too much gain. I think documenting this should do good enough job