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