[Fedora-packaging] New packaging guidelines for Ruby

[Toshio Kuratomi]

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