buildr as an rpm

Adam Young ayoung at redhat.com
Fri Apr 2 01:57:39 UTC 2010


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.
>
>

Just to confirm, I yumdownloaded the source rpm, rebuilt, and then 
compared to the official.

[ayoung at localhost devel]$ diff -r mine/ official/
Only in official/usr: lib
Only in mine/usr: lib64

I think thats a bug




More information about the candlepin mailing list