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