On Fri, Jan 20, 2012 at 9:38 AM, Mo Morsi <mmo...@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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig