buildr as an rpm

Jesus M. Rodriguez jmrodri at gmail.com
Fri Apr 2 14:54:38 UTC 2010


On Thu, Apr 1, 2010 at 9:43 PM, Adam Young <ayoung at redhat.com> 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/

On a x86_64 box the proper location *IS* /usr/lib64

>
>
> I supect the reason that this works for us, or anyone, is that everyone
> runs
>
> sudo gem update --system

We should NEVER run gem update --system if we are using rpm based gems.


jesus



More information about the candlepin mailing list