New Ruby Guidelines Draft

Vít Ondruch vondruch at redhat.com
Tue Jan 3 15:12:44 UTC 2012


Dne 3.1.2012 16:07, Scott Seago napsal(a):
> On 12/23/2011 04:39 AM, Vít Ondruch wrote:
>> Dne 22.12.2011 17:45, Mo Morsi napsal(a):
>>> On 12/22/2011 11:19 AM, Scott Seago wrote:
>>>> On 12/22/2011 09:09 AM, Vít Ondruch wrote:
>>>>>> - In the Rubygems section:
>>>>>>
>>>>>> "For every dependency on a Gem named|gemdep|, the package must contain a|Requires|  on|rubygem(%{gemdep})|  with the same version constraints as the Gem"
>>>>>>
>>>>>> Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
>>>>>
>>>>> You are right. We should not be as strict. Actually, I believe 
>>>>> that we should not use version unless necessary. We will try to 
>>>>> polish this formulation according to your suggestion.
>>>> Actually, we need to be very careful here. We've been bitten in the 
>>>> past by creating RPMs with deps that don't strictly follow the gem 
>>>> deps, since you then have a gem installed that, strictly speaking, 
>>>> doesn't meet its gem dep requirements. If you end up using bundler 
>>>> for something, it's going to complain. We had a big problem with 
>>>> this when we had an RPM for which the underlying gem required rspec 
>>>> (2.0+), but we required the rspec sub-packages instead.
>>>>
>>>> Scott
>>>
>>> Ah good point. Actually now that I think about it the guidelines 
>>> could use something to the effect of how to integrate bundler and 
>>> other alternative gem-dependency management into all of this (its 
>>> been a royal pain up to this point).
>>>
>>> If nothing else, perhaps a guideline stating that if you modify the 
>>> gem dependency list in the rpm spec, you must ensure that it is 
>>> modified in bundler's Gemfile as well.
>>
>> Something more important should be there. If RPM modifies some gems 
>> dependencies, then the .gemspec should be updated accordingly. I know 
>> that I forget to do it several times and there were probably also others.
>>
> Yes, this is exactly my point -- the problem I ran into was when we 
> modified the RPM deps in a way that contradicted the gemspec, but the 
> gemspec wasn't modified accordingly. If RPM deps are modified and the 
> gemspec is modified accordingly, the conflict goes away. The main 
> point is that if the installed gem has missing deps, we have a 
> problem. If we modified the gemspec to reflect the RPM deps, then any 
> ruby code that cares about gem dependencies (such as bundler) will 
> continue to work fine.

We tried to work on the draft a bit. This is formulation we came up with:

The package must provide rubygem(%{gem_name}) where gem_name is the name 
from the Gem's specification. For every dependency on a Gem named 
gemdep, the package must contain a Requires on rubygem(%{gemdep}). 
Packager must ensure that the package works properly with its specified 
dependencies. Please note, that Fedora may carry different versions of 
Gems than those specified in Gem's .gemspec, therefore the versions 
required in specfile may not match the dependencies in .gemspec exactly. 
In that case, the .gemspec file must be adjusted accordingly.


Vit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120103/ec76164a/attachment-0001.html>


More information about the ruby-sig mailing list