Mohammed Morsi wrote:
Just uploaded a new Ruby 1.8.7 SRPM which reverts the search path to
what it was in Ruby 1.8.6.
http://mo.morsi.org/files/ruby-1.8.7.249-4.fc13.src.rpm
You beat me to it. Thanks.
There is one major change, as noted before even though the Ruby
1.8.6
rpm included /usr/lib64/site_ruby in the search path, this directory
does not exist and is not created / provided by the rpm, so I omitted
it. If there is a valid reason for its inclusion, it can be readded,
I confirm that the paths containing /usr/lib64/site_ruby are removed
but the rest are in order:
$ LD_LIBRARY_PATH=. ./ruby -e 'puts $:'|sdiff -w78 orig-path -
/usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8
/usr/lib64/ruby/site_ruby/1.8 /usr/lib64/ruby/site_ruby/1.8
/usr/lib64/ruby/site_ruby/1.8/x86_64- /usr/lib64/ruby/site_ruby/1.8/x86_64-
/usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby
/usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby
/usr/lib64/site_ruby/1.8 <
/usr/lib64/site_ruby/1.8/x86_64-linux <
/usr/lib64/site_ruby <
/usr/lib/ruby/1.8 /usr/lib/ruby/1.8
/usr/lib64/ruby/1.8 /usr/lib64/ruby/1.8
/usr/lib64/ruby/1.8/x86_64-linux /usr/lib64/ruby/1.8/x86_64-linux
. .
I think it would be prudent to include all three.
That they are listed in ruby's default path is reason enough.
That may have encouraged some people to create and use one
or more of the directories. Whether the 1.8.6 rpm actually
created/owned them isn't the issue. People may be relying on
those being in ruby's default search path.
but the RPM itself should be updated to generate and own it. (Also
the
1.8.7 subdirs for the parallel stacks in included, but commented out
with a note to uncomment when needed)
I didn't change the approach to the multilib patch as there doesn't
seem to yet be a consensus as the best way to conditionally apply
it. I honestly can go whichever way so long as the final solution is
understandable / standards compliant.
I see you are still using this approach:
%build
export LIB_PREFIX=%{_lib}
Using that approach causes the "make ... && cd r*9/r*9 && make
..."
idiom to subtly malfunction if it ends up running mkconfig.rb.
Finally, IMO i think we should be basing our work off my latest
SRPM. I spent a lot of time removing uneeded cruft and consolidating
related bits together, and I think it will provide the simplest way
moving forward (especially with the parallel stacks stuff)
One more nit in your spec file:
------------------
%configure \
...
--with-sitearchdir='%{ruby_sitearch}' \
--with-vendordir='%{ruby_vendorlib}' \
--with-vendorarchdir='%{ruby_vendorarch}' \
# For example ext/socket/extconf.rb uses try_run (for getaddrinfo test),
------------------
Currently that final trailing slash doesn't cause trouble,
but it'd be better to remove it, in case someone accidentally
adds something intended to be a separate statement right after it.