warning: rspec.rb provided by rubygem-rspec
by Mo Morsi
rspec1 shipped rspec.rb as part of the rubygem-rspec package
rspec2 shipped rspec.rb as part of rubygem-rspec-core, so to assist in
that migration we left rubygem-rspec at 1.x for the time, and converted
packages to depend on rspec-core. When the migration was done, we
updated rubygem-rspec.
rubygem-rspec was just updated in rawhide to 2.11.0 which again provides
rspec.rb (which was removed from rspec-core 2.11.0). So packages just
depending on rspec-core will now need to pull in rspec to be able to use
rspec.rb
The fix is easy enough, just a word of warning if you see related errs
in broken builds w/ gem packages starting in rawhide.
rspec also depends on an updated version of diff-lcs, which is available
in rawhide (thanks mamoru & vit!)
-Mo
10 years, 7 months
JRuby masterplan for F19 - RFC
by Bohuslav Kabrda
Hi all,
as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest:
* Global changes
- As already mentioned in [1], change the default operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future.
- Add additional macros to macros.rubygems, see [3] (if the macros names seem confusing, see the section about packaging gems for JRuby below).
- Two connected problems: 1) RPM generates auto provides from shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby?
-- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime.
-- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install.
-- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang.
* Changes to packaging
- Platform independent packages mustn't R: ruby, unless there is a specific reason to do so.
- Packages with MRI binary extensions will have to R: and BR: ruby explictly, not just ruby(abi), as that will also be provided by JRuby.
- Packages meant only for JRuby will have to R: and BR: jruby explictly (same reason). These will use the %gem_extdir_jruby macro.
- Packages with extensions for both Ruby and JRuby (let's consider rubygem-json, example of converted specfile is at [4]):
-- MRI extension will probably stay in the core package (rubygem-json).
-- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros.
-- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5).
-- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed.
or
-- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this.
-- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby.
* Others:
- There is also a general problem with Provides/Requires of the interpreters themselves. I think that JRuby should provide both ruby(abi) = 1.9.1 and ruby(abi) = 1.8. I'm however not sure whether to provide e.g. rubygem(io-console), which is required by rubygems package. The problem with this provide is this:
1) user installs JRuby (that provides rubygem(io-console)) and rubygems.
2) user installs MRI, rubygem-io-console doesn't get installed, as the dependency is already satisfied.
3) "gem" command (specifically its part that depends on io-console) run under MRI fails.
As I see it, we probably won't get rid of having MRI ruby installed with JRuby, at least not for the near future (but at least the auto-requires of /usr/bin/ruby can be handled, which is a step in the right direction).
I hope I made my points clear, please share your thoughts/comments/critisism.
BTW, I'll be updating my testing repo with JRuby as soon as JRuby 1.7.1 are out. When we agree on how the stuff mentioned above should work and have it approved by FESCo/FPC, I'll start pushing JRuby into F19, but that seems to be far away for now...
Thumbs up if you read the whole mail :)
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-November/001142.html
[2] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...
[3] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/rubygems.spec#...
[4] https://github.com/bkabrda/jruby.spec/blob/master/rubygem-json/rubygem-js...
10 years, 8 months
Rubygem RPMs and "bundle install"
by Philip Rhoades
People,
I have just upgraded to Fedora 18 x86_64 and installed all the
Ruby/Rails RPMs but I notice when I create a test rails app and then add
something to Gemfile and do "bundle install", the system starts pulling
in all the native Gems - I would like to stick to just using RPMs - so
is there a changed procedure for the RPM environment?
Thanks,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil(a)pricom.com.au
10 years, 8 months
Heads up: Rails 3.2.10 in Rawhide
by Vít Ondruch
Hello everybody,
The Rails 3.2.10 will be soon in Rawhide. The build is already in its
second half, but it takes ages. Please let me know if you encounter any
issues.
Vít
10 years, 8 months
Rubygem RPMs and "yum update"
by Philip Rhoades
People,
I have just upgraded to Fedora 18 x86_64 and installed all the
Ruby/Rails RPMs but I notice when I create a test rails app and then add
something to Gemfile and do "bundle install", the system starts pulling
in all the native Gems - I would like to stick to just using RPMs - so I
presume "bundle install" does not get used in the change to the RPM
environment? (ie I should manually install the missing gem RPMs).
Also, I presume one has to be careful about doing a system-wide update
of RPMs with "yum update" in case updated Gems break stuff specified in
Gemfile.lock?
Thanks,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil(a)pricom.com.au
10 years, 8 months
