> 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? >
Exactly. > 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 Yes, we may not have enough influence, but we should not stop trying :) Regards, Slavek. _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
