This page describes stuff relating to ruby and ruby* ports in tree for ruby@
Current list of people in ruby@
How to commit for ruby@?
More to come for this, but one of the key things to remember is that when you update a gem, you must at least build all the things that depend on it. Also note that gems can be patched using normal patch files now, which is sometimes useful for updating versions of dependencies.
You can find some of ruby@ people on EFNet and FreeNode IRC. There is now a #rubyports on EFNet. Feel free to connect and ask questions or discuss a future of ruby ports on FreeBSD.
Gem packaging FAQ
Why does the FreeBSD community package gems? Can't you just use bundler?
All users, including both end users of classic applications, and system administrators who will install web applications, have different needs. One of the goals of Ports is to build some packages that can be used to either build from ports or simply pkg install. Gem is also essentially a package manager. Some prefer not to use one packaging system for installing their web server and another for installing the web application they run in that web server (and it's dependencies), instead just using one package system for everything. Also, gems are often updated, but some prefer to always stick with known good versions of software before upgrading, so they like to have the same versions of packages all the time, even building themselves and using the same package files across many systems. Gem bundles often install compatible but slightly different versions of the same software (gem version 1.1.1 vs gem version 1.1.2, for example).
Properly and securely building software packages does create some restrictions. For example, when packages are built, the build can only download software during the "fetch" phase of ports building. Fetch during patch, build, install, etc. are not allowed. There are good reasons for that of course, but it adds some complexity. This conflicts in some sense with gem which fetchs, builds and installs all in one step.
Another part of the reason we package gems is that it simplifies things. A user can simply "pkg install redmine" and, baring any bugs and local config, have a working redmine install. This will include the redmine software, it's gem dependencies, the web server, any ImageMagick dependencies that might exist, etc. Contrast this with using the pkg to install just the web server and ImageMagick software, then using bundler to install gems and redmine.
Ports could perhaps be setup to call bundler, but this would complicate the package building, particularly where one package shares dependencies with another. And this would really violate the packaging requirements as well.
Why do you patch gems?
There are many reasons gems get patched. Sometimes it's due to compile time issues, for those gems which contain C extensions. Other times, it's just adding special cases for things related to FreeBSD, such as system related gems. We always strive to work with upstream developers on all local patches.
One of the most common reasons gems are patched in ports is changing version requirements of dependencies. Ports doesn't support installing multiple versions of the same package as easily as gem, yet some ports depend on the same gem but different versions of it. For example:
Port X depends on gem XYZ version ~> 1.0.1
Port Y depends on gem XYZ version ~> 1.1.1
This creates a conflict in ports or creates extra work creating a port for both 1.0.1 and 1.1.1. (This happens because gem and ruby software authors follow the default pessimistic version constraints shown on rubygems.org which suggests depending on the exact patch versions of a gem. We're referring here to the suggested depend line like:
gem "XYZ", "~> 1.0.1"
This overly strict dependency version requirement isn't necessary as long as gems are following semantic versioning. So often in order to avoid extra work, we patch things to use less restrictive versions of dependencies. Simply changing to requirement to 1.1 makes life easier for everyone and almost always works properly.