Heads up: Rebuild for Ruby 1.9.3

Thu Jan 26 07:49:52 UTC 2012

Dne 25.1.2012 22:46, Mo Morsi napsal(a):
> On 01/25/2012 03:40 AM, Vít Ondruch wrote:
>> Dne 25.1.2012 00:52, Rex Dieter napsal(a):
>>> Mo Morsi wrote:
>>>
>>>> On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
>>>>> Hi,
>>>>> since we finally got our Ruby 1.9.3 feature page [1] approved, we are
>>>>> starting rebuild for Ruby 1.9.3. Everyone who owns a package that 
>>>>> depends
>>>>> on Ruby or Rubygems should rebuild it in the special Koji target
>>>>> "f17-ruby". This target will be merged into rawhide just before the
>>>>> branching, which will occur on 2012-02-07. After this deadline, 
>>>>> you will
>>>>> need to go through the standard Bodhi update process. The detailed
>>>>> instructions on rebuilding the packages, including our suggested 
>>>>> changes
>>>>> can be found in [2]. Feel free to contact me or Vit Ondruch 
>>>>> (vondruch at
>>>>> redhat dot com) or write to ruby-sig mailing lists, if you run 
>>>>> into any
>>>>> kind of problems.
>>>>>
>>>>>
>>>> I'm somewhat confused. Has the issue w/ sudo gem install been 
>>>> resolved?
>>> Any citation or bug references for this problem you mention?
>>>
>>> -- rex
>>>
>>
>> Let me clear the situation. First of all, this is not issue of "sudo 
>> gem install". That command works just fine. That is issue with 
>> Bundler. Unfortunately, Bundler is one big hack above RubyGems based 
>> on some assumptions which are not true. It can be seen on its code 
>> where is a lot of custom logic for specific version o RubyGems and 
>> Bundler has a lot more quirks with regard of its usage on package 
>> driven systems. It can break for example with every upstream change 
>> of RubyGems. Now what is the issue:
>>
>> Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally 
>> broke the FHS. We tried to remove this breakage with Ruby 1.9. 
>> RubyGems traditionally installs their binary extensions into the same 
>> place as their platform independent code, incompatible with FHS. To 
>> be somehow compatible with FHS, this was changed and for Ruby 1.8, 
>> the binary extensions were installed into ruby_sitedir. That results 
>> in conflicting binary RPMs which conflicts among their versions, 
>> although this was never the case for RubyGems packages. So for Ruby 
>> 1.9.3 we tried to work on this issue and we modified RubyGems to be 
>> able to load the libraries, where the noarch part is placed in share 
>> and the binary library in lib, so RPM packaged gems are installed 
>> into /usr/share and their binary libraries into /usr/lib. Moreover, 
>> we changed how RubyGems works, e.g. by default, "gem install" 
>> installs gems into your home directory, so you don't need sudo to 
>> work with gems anymore. However, if your are using "gem install" with 
>> root users, they are installed into /usr/local/share and their binary 
>> libraries are installed into /usr/local/lib.
>>
>> Now there comes Bundler. Assuming it knows everything about RubyGems, 
>> they put together their custom logic how to populate Ruby's load 
>> paths, which does not work well with changes we made into RubyGems, 
>> i.e. it cannot add the binary extension path to the Ruby's load path, 
>> resulting in failure when loading the gem. Nevertheless, this is 
>> going to be handled in RPM packaged Bundler and it will work properly 
>> as long as user uses RPM packaged Bundler. Once somebody installs 
>> upstream version of Bundler, the Bundler fails naturally.
>>
>> So there are probably 4 solutions to this issue:
>>
>> 1) Always use Bundler provided by Fedora which will works as it should.
>> 2) Force Ruby and RubyGems upstream to properly support FHS. I 
>> already provided patches [1] but I need your support.
>> 3) Revert the customized behavior of RubyGems and break FHS.
>> 4) Treat root as regular user and install gem also into root's home 
>> directory, but it obviously doesn't make sense.
>>
>> So obviously I have chosen 1) and trying to move forward with 2). 
>> That works most of the times. It breaks only in situation, when you 
>> install upstream Bundler using "sudo gem install" and later you want 
>> to use some system wide gem with binary extension. If you install 
>> gems using "gem install" into your home dir (preferred, default way), 
>> it works every time. Mixing of RPMs with other package managers has 
>> its limits and this is one of them.
>>
>
>
> OK so the only thing that will not work after everything is said and 
> done is running 'sudo bundle install' if you've installed bunder via 
> 'gem install bundler' and not 'yum install rubygem-bundler' correct?
>
> If that is the case, I can live with this as running 'bundle install' 
> as sudo is discouraged upstream anyways. I've seen a few cases which 
> this is used as a hacky workaround, but I think the intention on 
> bundler is to vendorize dependencies locally and is not meant for 
> system-wide management.
>
> My only concern is that upstream practices will change yet again in a 
> manner which our reworking of the load paths to conform to the FHS 
> will be incompatible. Try as we might, I don't believe the Fedora ruby 
> community has enough sway with the upstream ruby community to change 
> their practices (yet) so I'm willing to go forward with this new 
> direction provided that if it becomes incompatible w/ a widespread 
> upstream practice down the road, we evaluate the situation and 
> possibly make the necessary changes to play well w/ the Ruby 
> community. At least until the day we can reasonably influence the 
> direction of the upstream practices.
>
>   -Mo
>
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Nicely summarized.

BTW Red Hat already employs one of ruby-core commiters, so who knows ;)

Vit