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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig