[Fedora-packaging] New packaging guidelines for Ruby

Vít Ondruch vondruch at redhat.com
Tue Feb 28 17:25:22 UTC 2012


Dne 28.2.2012 18:05, Rex Dieter napsal(a):
> On 02/28/2012 10:56 AM, Vít Ondruch wrote:
>
>>
>> All three versions provide the same output, unless I did some mistake,
>> since I did not tested it (actually the middle one was taken directly
>> from rubygem-POpen4.spec). So which version you prefer? Please note that
>> the "gem install" will always "unpack" the gem with some additional, for
>> our case unimportant, steps. We do not distribute the .gem file 
>> anywhere.
>
> You didn't exactly (directly) answer my question.  Pretend I don't 
> know much about ruby... (not far from the truth).
>
> So, for rubygem packages that include native (C or otherwise code), 
> how and when is this compiled?  If it is always done so during either 
> version of these guidelines, please do accept my apologies for being 
> ignorant.

It is compiled during the "gem install" step. So "gem install" is doing 
%prep, %build, %install in one step. So yes, it is always done for 
either version of guidelines.

>
> However, you do say you do not distribute the .gem, though I'm curious 
> why this seem to contradict you:
>
> rpm -qlp rubygem-POpen4-0.1.4-3.fc17.noarch.rpm
> /usr/share/gems/cache/POpen4-0.1.4.gem
> ...
>

I knew you will point it out :).

It is cached version of the original gem, which RubyGems may use to 
restore the gem into its original state (and may be other unknown 
purposes). However, it is not used in runtime, nor it is good idea to 
restore the gems maintained by RPM by gem command. Moreover, even though 
the gem would not be available in the cache dir, RubyGems will download 
it. Hence we add new clause into the packaging guidelines:

Since the Gem is installed using RPM, you *must* exclude the .gem file.


Vit


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120228/2f118fa0/attachment.html>


More information about the ruby-sig mailing list