Gentoo Ruby ProjectThe Ruby project maintains packages for Ruby implementations, libraries and development tools. This project also maintains the RubyGems package, the de facto standard for packaging Ruby projects. Many Ruby packages currently in the Portage tree use this mechanism for installing. Highlighted packages include Rake, Ruby on Rails, Capistrano, and RSpec, to name a few.
All developers can be reached by e-mail using nickname@gentoo.org. 3. Supported Ruby implementations In Gentoo multiple Ruby implementations can co-exist. This is supported through the RUBY_TARGETS mechanism. You can add the RUBY_TARGETS variable to your /etc/make.conf file to select which Ruby implementations you want packages to be installed for on your system. By default only ruby18 is selected.
This version of Ruby is our main implementation. It is available as the 1.8 slot of dev-lang/ruby. It is available in the stable tree, and almost all Ruby packages in the tree are available for this implementation.
Ruby 1.9.x (aka MRI/YARV): ruby19 This version of Ruby is also stable and available as the 1.9 slot of dev-lang/ruby. This version will become the default ruby implementation for Gentoo after the summer of 2012. This version of Ruby is based on the Java Virtual Machine. It is available as dev-java/jruby. It is available in the stable tree. Ruby Enterprise Edition 1.8.x: ree18 This is an enhanced version of Ruby 1.8, featuring various enhancements, most notably in that it requires less memory to run. It is available as dev-lang/ruby-enterprise It is available in the stable tree. For more information, visit http://www.rubyenterpriseedition.com/.
Rubinius is currently available in the unstable tree and should be considered experimental. There are still a few packaging bugs that keep it from being used more widely. We are currently looking for users interested in helping the project with the following jobs:
The tasks of the Ruby project are: Ruby 1.9 - Support for all Ruby packages with 1.9 Ruby 1.9.1 is going to be the first stable release of Ruby 1.9, to be released in January 2009. Our infrastructure is currently being updated, so we should have ebuilds in the near future.
Resources offered by the Ruby project are:
7. Policy for adding new Ruby packages The ruby herd gets a fair amount of requests to add new packages to the dev-ruby category in Portage. Unfortunately we often get a bit defensive about this and the package requests just hang about. This policy tries to outline our thinking on when to add new packages and what you can do to enhance the chances of adding a new package. Which packages should go to dev-ruby? The dev-ruby category should only contain the following packages:
Specifically, applications written in Ruby should not go to the dev-ruby category by default, and they would not normally be maintained by the ruby herd. For example, recently cucumber has been added to the dev-util category, even though it is written in Ruby and started out as a spin of from the more Ruby-specific rspec. However, it now also has support for Java and it provides an application, so it is much better suited for a more targeted category of dev-util. For libraries and supporting code we tend to add these packages only when they are a requirement for an application that gets added to Gentoo, or a new requirement of said application. Other packages only get added when there is sufficient demand. We determine this by looking at the number of votes for a package, so feel free to open a bug for it and lobby a few folks to add their votes. Having this policy may seem silly. Why not just add new packages as people provide ebuilds for them? In part we are reluctant to add many packages because they should really fall under the responsibility of someone else. For example, sup, the ruby mail client, fits much better to the net-mail herd. After all, not all packages written in C are part of the (not even existing) c herd. In part we are also reluctant because once a package is added it will increase our workload towards the future. Version bumps, security issues, and QA within Gentoo must be kept up to date. On top of that ruby has a bit of a reputation for code that sees a few frantic releases and is than for all intents and purposes abandoned. Having packages like that in the tree adds disproportionally to our maintenance and takes away from providing you with an overall good ruby experience on Gentoo. 8. Version bumps for existing packages We automatically track updates to gems-based ruby packages, so please don't file bugs for these at all. (Note that the list in question is generated on-demand manually, so it may appear to be out of date.) If a gems-based package has not been updated to the latest version for some time then this usually means there are issues with it. In that case the best way to help us is to report a bug that includes a fully tested version of an ebuild. The ebuild should work correctly with FEATURES=test and USE=doc on all the ruby implementations that the ebuild supports. For other ruby packages we don't have a centralized mechanism to track new versions, but we still track a fair amount of them by other means. If you find such a package that has not been updated for a month then please feel free to file a bug for it since we may not be actively monitoring it. Please double-check that it is not (also) distributed as a gem to avoid unnecessary bugs. |
|