[Fedora-packaging] New packaging guidelines for Ruby

[Bohuslav Kabrda]

----- Original Message -----
> On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda <bkabrda at redhat.com>
> wrote:
> > ----- 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,
> applications,
> and scripts will break when the user runs with the --disable-gems
> option.
> 
> 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
> non-gem
> 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.
> 
> -Toshio

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:

begin
  require 'mocha'
rescue LoadError
  Mocha = nil
end

if Mocha then
  # ...
else
  # ...
end

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.

-- 
Regards,
Bohuslav "Slavek" Kabrda.