buildr as an rpm

Bryan Kearney bkearney at redhat.com
Fri Apr 2 13:45:53 UTC 2010


On 04/01/2010 10:13 PM, Adam Young wrote:
> On 04/01/2010 09:43 PM, Adam Young wrote:
>> On 04/01/2010 08:13 AM, Bryan Kearney wrote:
>>> On 04/01/2010 07:58 AM, Adam Young wrote:
>>>> Wah wah wah...I spent 45 minutes doing something that I should have
>>>> done
>>>> in 15 minutes using a script.
>>>>
>>>> Here's what needs to be done now:
>>>>
>>>> 1. Clean my machine from all Ruby and re-install just the RPMs without
>>>> the system update
>>>> 2. Build the Buildr rpm...missed that one
>>>> 3. Run RPM lint on each rpm.
>>>> 4. Go through the Ruby RPM standards and compare to SPEC files
>>>> generated by gem2rpm. Make any cleanup there.
>>>> 5. Submit to Fedora for Rawhide
>>>
>>>
>>> FWIW.. the last i used gem2spec
>>> (https://bugzilla.redhat.com/show_bug.cgi?id=540996) it was not up to
>>> date with the goofy new ruby standards.
>>>
>>> -- bk
>> I think there is an error in the spec file, and the standards.
>>
>> At the top of the file, if you put:
>>
>> %global gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
>>
>> You get a gemdir of /usr/lib64 on a 64 bit system, and /usr/lib on a
>> 32 bit system. But this is, If I am not mistaken, not reset at install
>> time, but instead used from the machine value at build time.
>> Otherwise, I can't explain why all of the F12 Yum repo ruby gems
>> install into /usr/lib/ruby/gems/1.8/gems/ but updated versions end up in
>>
>> /usr/lib64/ruby/gems/1.8/gems/
>>
>>
>> I supect the reason that this works for us, or anyone, is that
>> everyone runs
>>
>> sudo gem update --system
>>
>> Which pulls down the latest versions of the installed gems.
>>
>>
>
>
> The culprit is actually the instruction on the candlepin build site:
>
> sudo gem update --system
>
> This changes the value of ruby -rubygems -e 'puts Gem::dir' from
> /usr/lib/ruby/gems/1.8 to /usr/lib64/ruby/gems/1.8
>
How/Why does it switch that?

-- bk




More information about the candlepin mailing list