Use rubygem(foo) or rubygem-foo

Vít Ondruch vondruch at redhat.com
Mon Jan 20 10:54:14 UTC 2014


Dne 20.1.2014 11:11, Mamoru TASAKA napsal(a):
> Mamoru TASAKA wrote, at 01/20/2014 07:00 PM +9:00:
>> Achilleas Pipinellis wrote, at 01/20/2014 07:37 AM +9:00:
>>> I know that both result to the same thing (if I remember correctly I
>>> had
>>> asked Vit about this in IRC), but I have forgotten their real
>>> difference.
>>>
>>> My attention got caught by a comment Josef made in one of his reviews
>>> [0], saying that rubygem-foo is the new syntax. If that's the case, I
>>> would like to propose 2 changes:
>>>
>>> a) A reference in the wiki
>>> b) An implementation for gem2rpm
>>>
>>> I guess b) could be fairly easy by changing the templates.
>>>
>>> By starting with these steps, there will be a push to use the new
>>> syntax
>>> from now on. What do you think?
>>>
>>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=979749#c2
>>>
>>
>> Please use syntax other interpreters do:
>> https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl#Perl_Requires_and_Provides
>>
>> https://fedoraproject.org/wiki/Packaging:PHP?rd=Packaging/PHP#Requires_and_Provides
>>
>> https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml#Requires_and_provides
>>
>>
>> i.e. use rubygem(foo), not rubygem-foo.
>>
>
> Additional explanation:
>
> The idea here is that ideally like perl or so and pkgconfig(foo), etc,
> this type of
> dependency should be handled by rpmbuild _automatically_, i.e.
> rpmbuild automatically
> adds provides/requires rubygem(foo). Currently this is done by
> gem2rpm, however if
> this could be done on building rpmbuild side, it would be more
> appreciated.

It is doable, but we should still clarify what does it mean, i.e.

1) is it rubygem(%{gem_name}) or
2) should it be rubygem(typical_file_you_should_require), where for some
gems, there might be more of these provides.

I think it would be good to do it for F21, since I am going to propose
guideline changes anyway. Hope I'll find some time to play with this.


Vít


More information about the ruby-sig mailing list