Fwd: Re: ruby 1.8.7.x for rawhide

[Mohammed Morsi]

On 06/23/2010 04:49 PM, Jim Meyering wrote:
> 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.
>
>    

Readded, though honestly I'm not a fan of this reasoning. If its not in 
the Fedora / Ruby guidelines, it's not supported and thus we shouldn't 
add the additional complexity. Furthermore this approach would result in 
none of the paths ever changing, which obviously we don't want. Going 
forward we should identify only the paths that are supported and only 
include those.

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

Done, changed it to use your patch.

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

Done.

New SRPM uploaded:

   http://mo.morsi.org/files/ruby-1.8.7.249-5.fc13.src.rpm

   -Mo