Heads up: Rebuild for Ruby 1.9.3

[Bohuslav Kabrda]

> 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.