On Tue, Feb 28, 2012 at 4:47 AM, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> 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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
