More 1.9.3 fun

Michael Stahnke mastahnke at gmail.com
Fri Jan 20 18:15:55 UTC 2012


On Fri, Jan 20, 2012 at 9:38 AM, Mo Morsi <mmorsi at redhat.com> wrote:
> On 01/20/2012 03:58 AM, Vít Ondruch wrote:
>>
>> Dne 19.1.2012 21:52, Mo Morsi napsal(a):
>>>
>>> On 01/19/2012 03:16 AM, Vít Ondruch wrote:
>>>>>
>>>>>
>>>>> So, obviously the bundle can't find the C extension.  According to
>>>>> some research, I see this on rubygems.org
>>>>>
>>>>> "This works because rubygems copies the shared object from ext to lib
>>>>> when the gem is installed."
>>>>>
>>>>> I'm not sure that's happening.
>>>>
>>>>
>>>>
>>>> Actually that's happening, just a bit differently. You see that you have
>>>> the '/usr/local/lib/gems/exts/sqlite3-1.3.5/lib/sqlite3/sqlite3_native.so'
>>>> so it is in libs and if you run "$ ruby -r sqlite3 -e "puts 'it works'"",
>>>> RubyGems should prepare the load paths and everything should work.
>>>>
>>>> Unfortunately Bundler does not use RubyGems to prepare the load paths
>>>> and it is doing everything by itself. Therefore Bundler doesn't know about
>>>> this modifications we made to RubyGems and cannot load the library properly.
>>>> Moreover, Bundler replace the RubyGems modified 'require' by the Ruby's
>>>> original version, so RubyGems cannot help here.
>>>>
>>>> We are looking into Bundler now to find a cure. Unfortunately, that
>>>> means you will not be able to use stock Bundler in Fedora anymore. The only
>>>> option is to push the RubyGems modifications upstream [1], and later push
>>>> the changes into Bundler's upstream. However, RubyGems upstream is not very
>>>> responsive in this matter. May be you can try to support us a bit.
>>>>
>>>
>>> Yes, seems to be a pretty big blocker. The new paths should allow us to
>>> use both the version of bundler shipped via rpm and bundler if installed via
>>> gem.
>>>
>>> We can push for different practices upstream but that is quite an effort
>>> w/ no guarantees, and most likely won't be implemented by F17. If we can't
>>> figure out a solution to get bundler working at a technical level, this will
>>> have to push the 1.9.3 release back.
>>>
>>
>> To clarify things a bit, RubyGems as they are prepared for F17, will
>> install your custom gems into your home directory. If you are doing so,
>> Bundler should have no issues. If you want to deploy your application, it is
>> best if you are going with RPM packaged gems, including RPM Bundler. If you
>> are going to install gems system-wide, using gem install as a root, you are
>> "asking for troubles" (yes, it is a bit exaggerated :)) and you should know
>> what are you doing.
>>
>>
>> Vit
>>
>
> The problem is, installing gems system-wide as root is a valid use case,
> which is often practised in the upstream ruby community. Putting comments
> aside on the wisdom of such practices, I've seen many ruby applications
> instruct the user to install dependencies via 'sudo gem install'.
>
> If this use case is broken under Fedora 17, this will be a regression as far
> as our community's support. This is a big enough blocker that we can't
> accept it, so we'll need to figure out a solution or hold off the release
> until one is engineered. I don't forsee this taking too long, even if it
> involves some guidelines or upstream bundler work, though may cause us to
> miss the F17 target.
>
The reason this stuff is going in as root, is that it's happening via
Puppet, and following the upstream instructions (of this rails
project) on how to operate.  I don't think we can/should cripple that
feature.

I can make it work with managing sylminks, patching bundler, editing a
Gemfile etc; however the end-user experience with Ruby needs to be
painless, and this certainly isn't.

I do have the bigdecimal package installed.
>
>  -Mo
>
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


More information about the ruby-sig mailing list