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@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 > > 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
Attachment:
pgp86211o0uKt.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
