ruby 1.8.7p299 is now rawhide build tree

[Mohammed Morsi]

On 07/26/2010 03:53 PM, Mamoru Tasaka wrote:
> Hello, all:
>
> As
> - F14 feature freeze is tomorrow !
> - Mohammed's ruby srpm was almost complete (as far as I tried using):
>    http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
>
> I slightly modified Mohammed's srpm and imported into rawhide build tree.
> Now it is available on
> http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
>
> A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
> - Some cleanups
> - Make -irb, -rdoc subpackage noarch
> - Make dependencies between arch-dependent subpackages isa specific
> - Improve sample documentation gathering
>
> I hope the imported new ruby won't break things (so much).
> I appreciate all peoples' contributing to ruby 187 packages.
>
> Regards,
> Mamoru
>
>    
Thanks for this Mamoru, just went through and rebuilt your srpm, and 
have a couple of comments:

Some rpmlint output:

$  rpmlint /home/mmorsi/rpmbuild/SRPMS/ruby-1.8.7.299-4.fc13.src.rpm

 > ruby.src: W: no-cleaning-of-buildroot %install
 > ruby.src: W: no-buildroot-tag
Are the result of removing "BuildRoot" and "rm -rf $RPM_BUILD_ROOT " as 
per the following guidelines, and can be ignored correct?

http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag

 > ruby.src:264: W: mixed-use-of-spaces-and-tabs (spaces: line 264, tab: 
line 1)

You have a tab on the "-mindepth 1 \" line in the spec, this should be 
removed.

$ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-1.8.7.299-4.fc13.x86_64.rpm
 > ruby.x86_64: W: obsolete-not-provided ruby-mode
 > ruby.x86_64: W: obsolete-not-provided ruby-docs

In my latest spec I got around these by adding a 'Provides' for both 
ruby-mode / ruby-docs, where as you explicitly state "no Provides here". 
Is this the correct approach to do so? Eg if the emacs package provides 
the ruby-mode functionality, shouldn't it be that package that obsoletes 
and provides ruby-mode? Also since our package Obsoletes ruby-doc 
shouldn't it provide it as well?

 > ruby.x86_64: E:  wrong-script-interpreter 
/usr/share/doc/ruby-1.8.7.299/sample/mpart.rb ./ruby

I had gotten around this by adding the following to my spec (in the 
section the other interpreter paths get corrected)

sed -i -e 's/^#!\s*\.\/ruby/#! \/usr\/bin\/ruby/' sample/mpart.rb

$ rpmlint 
/home/mmorsi/rpmbuild/RPMS/x86_64/ruby-tcltk-1.8.7.299-4.fc13.x86_64.rpm
 > ruby-tcltk.x86_64: E: non-executable-script 
/usr/lib/ruby/1.8/tkextlib/pkg_checker.rb 0644L /usr/bin/env

I got around this by removing the shebang from the top of the file like so.

sed -i -e '/^#!.*/,1D' ext/tk/lib/tkextlib/pkg_checker.rb

===

AFAIK all the other rpmlint warnings can be ignored. Just going through 
the spec file itself, I'm just wondering why the complexity for the 
iconv stuff. Unless I missed something major, I just went through the 
files rpmlint was stating weren't utf-8 and ran "iconv -f iso8859-1 -t 
utf-8" on them to take care of the issue. No need for any sed'ing. Did I 
oversimplify the issue?

Also I can't help but feel that we should put some of this stuff in the 
source %prep section, not in the %install section, and would be 
interested in seeing what (if anything) the guidelines say about this. 
Regardless these last couple are not big issues, I wouldn't have a 
problem with the Ruby rpms going in without them being resolved.


BTW I tested this latest RPM in a VM and am happy to say via some light 
surface testing: rake, rack, rails, rspec, and gem work out of the box, 
and the puppet, rails, and deltacloud test/spec suites work in the same 
manner as they do against 1.8.6.

We should be good to go for F14, though I don't think we'll pass through 
100% unscathed. There might be a few bug reports against some specific 
gems, but the major ones (and I'm guessing most others) should work fine 
and what doesn't can be taken on a case-by-case basis as they will need 
to be anyway.

Once again, thanks for the updated rpms and reviews.

   -Mo