[Fedora-packaging] New packaging guidelines for Ruby

[Toshio Kuratomi]

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

(1)
* My script has a "require 'mocha'" which, in Fedora is the packaged non-gem
* mocha has a "require 'latte'" which, in Fedora is only packaged as a gem.
  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..

(2)
* My script has a "require 'mocha'".
* mocha has a "require 'latte'" which in Fedora is only packaged as a gem.
* 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
  user's systems.

(3)
* 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
problem.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120302/16c8f39d/attachment.sig>