On Fri, Mar 02, 2012 at 12:42:26AM -0500, Bohuslav Kabrda wrote:
----- Original Message -----
> On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda <bkabrda(a)redhat.com>
> > ----- Original Message -----
> >> = ruby(name) vs rubygems(name) =
> > Here is one important reason why Gems should not provide
> > ruby(name):
> > The ruby(name) provides are supposed to be provided by the
> > libraries, that are meant to be directly loadable with "require
> > 'name'" even without Rubygems library. The Rubygems are loaded by
> > default in Ruby 1.9.3, but the users may choose not to load them
> > by passing "--disable-gems" option to the interpreter (either
> > directly or via environment variable RUBYOPT).
> > For a user, who turns of his Rubygems, a packaged Gem providing
> > ruby(name) wouldn't load, while some other non-gem package
> > providing ruby(name) would load, which is obviously a puzzling
> > behaviour.
> If the guidelines are to assume that people are going to be passing
> --disable-gems then they must require that non-gem subpackages exist
> for all gems. When a packager packages something that requires other
> ruby libraries they *must* inspect the code to see whether the code
> requires the gem or non-gem form. Otherwise, libraries,
> and scripts will break when the user runs with the --disable-gems
> However, the argument that non-gem is legacy behaviour and should no
> longer be represented in packaging has been made. After looking at
> how rubygems have become such an integral part of the ruby ecosystem,
> this seems reasonable to me but it does not just mean that the
> subpackages have been simplified away. It also means that the
> Provides and Requires situation has been simplified as well. If you
> want to keep the ruby()/rubygem() Provides split because people may
> run ruby with "--disable-gems" then we need to make non-gem
> subpackages mandatory as well.
A simple question: why would we mandate creating non-gem subpackages? If the developer
uses --disable-gems, then he knows he won't be able to require any gems. He may even
base his code on it:
Mocha = nil
if Mocha then
I believe that this simple piece of code says it all. The developer may be doing
something _based on the fact that rubygems are/are not loaded_. Therefore creating non-gem
subpackages should be forbidden. Please note, that --disable-gems can be used, for
example, for use-cases where hundreds of ruby interpreters run in parallel (not requiring
rubygems can make things significantly faster in this case), so I'm not just making
all this up.
If the developer codes something like that then a theoretical packaging of
the code does not need to have a Requires: ruby(mocha) either. So this
example doesn't show that Requires: ruby(mocha) or Requires: rubygem(mocha)
would have any effect.
Here's some examples of why I think that the Requires/Provides and the
subpackages go hand in hand:
* My script has a "require 'mocha'" which, in Fedora is the packaged
* mocha has a "require 'latte'" which, in Fedora is only packaged as a
ruby-mocha therefore has Require: rubygem(latte)
If I run my script with --disable-gem my script will fail even though mocha
was packaged as a non-gem and knew to Require the rubygem version of latte..
* My script has a "require 'mocha'".
* mocha has a "require 'latte'" which in Fedora is only packaged as a
* The ruby-mocha package has Require: ruby(latte) since someone could
attempt to run mocha with --disable-gems. Since there's no ruby(latte)
Provides, ruby-mocha will either not pass review or fail to yum install on
* The web application better-cms is packaged in Fedora. It Requires:
rubygem(latte) because it uses "require 'latte'"
* I install that application on my server.
* Because I want to make things faster, I try to run it with --disable-gems.
* It fails because latte cannot be found if rubygems are not loaded.
In all of these cases a strict Require on whether the package needs the gem
or non-gem version does not have an effect on whether the code in question
will run -- it fails in all instances. In all cases, having a non-gem
version of the gem libraries is one way to solve the problem. In all
instances, deciding that rubygems must be loaded would also solve the