I have pushed to my GitHub account updated version of .spec file which should reflect the most of your comments.
Dne 19.12.2011 13:43, Vít Ondruch napsal(a):
Dne 17.12.2011 19:26, TASAKA Mamoru napsal(a):
- build.log just shows:
compiling main.c compiling dmydln.c compiling dmyencoding.c compiling version.c
or so, It is hard to check from this log if Fedora specific compilation flags are passed correctly or not. Please make build.log more verbose so that we can see what commands are actually executed during build.
You are right that build of 1.8.7 was more verbose. However I can't see any difference in configuration or make flags. I'll try to take a look into it but I can't promise.
I found the option, so the build.log should be verbose as it used to be.
- Isn't COPY="cp -p" needed also on %install? Also "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults" in %spec file should be replaced by "cp -p".
Is it required at all? It is not used even in %install of 1.8.7, but there might be different reason. However there is guideline [5], so it is probably good idea.
I kept the install section without the "cp -p". The installation is done more or less by tool/rbinstall.rb and it seems the script does not honor the COPY variable. Moreover I checked the time-stamps and they look ok.
- Consider to move mkmf.rb to ruby-devel:
<mock-chroot>[root@localhost /]# rpm -q ruby ruby-1.9.3.0-2.fc17.i686 <mock-chroot>[root@localhost /]# rpm -q ruby-devel package ruby-devel is not installed <mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'" mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
Actually this is interesting idea. Never thought about it.
I created ticket for this issue for the record https://github.com/voxik/ruby.spec/issues/2
- rubygems rpm contains "bigdecimal-1.1.0.gemspec
io-console-0.3.gemspec json-1.5.4.gemspec minitest-2.5.1.gemspec"??
- At least these components should have its own subpackage rpms.
- Also, for example the latest minitest is 2.9.1. rubygems (or
rubygem-minitest built from ruby.... too complicated) should use latest minitest (and also please re-check components bundled in ruby - I hope ruby upstream will again unbundle these components ... this is again too complicated ..)
https://github.com/voxik/ruby.spec/issues/3
- include/ruby/ contains origuruma.h, however origuruma is separately packaged on Fedora. http://koji.fedoraproject.org/koji/packageinfo?packageID=5432 Can ruby use system-widely provided origuruma? If not, what prevents it?
This is though. I remember this lengthy discussion [4] about (not only) oniguruma and from that, I had the feeling that the upstream version is not compatible with Ruby. Moreover, I checked the latest sources from Fedora and from Ruby and they differs. I cannot imagine to patch Ruby to support the upstream library, although we can try to open request upstream? What do you think?
Do you still consider this as a blocker after upstream response [1]? Should I try to clarify or obtain exception from FPC just to be sure?
Vit
[1] http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/41721?41672-41...