English Portuguese (Brazil)
# ...
added via another `+%SOURCE+` tags
Add the commands you used to get the tests into the specfile as comments. This will make it a lot easier the next time you will need to get them.
Allows to override gem used for installation. This might get useful for converting legacy spec, so you might specify %\{SOURCE0} as a gem for installation.
*Alternate interpreters*:
Alternate Ruby interpreters (currently JRuby)
also `Provide: ruby(release)`.
This implies, that pure RubyGems packages (these are shared among interpreters) SHOULD NOT have `Requires: ruby` or `Requires: jruby` to have their dependencies satisfied by any of these interpreters.
Application packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the general xref:Naming.adoc[Naming Guidelines] instead.
Applications are
A sample spec for building gems would look like this:
*Be sure to test*: Do not simply change versions without testing that the new version works. There are times the upstream is overly strict but there are also times when the version requirement was specified because a specific bug was encountered or the API changed in a minor release.
Both RPM's and Gems use similar terminology; there are specfiles, package names, dependencies, etc. for both. To keep confusion to a minimum, terms relating to Gem concepts will be explicitly referred to with the word "Gem" prefixed, e.g., "Gem specification" (.gemspec). An unqualified "package" in the following always means an RPM.
Build Architecture and File Placement
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec
Building gems
pushd ./%{gem_instdir}
# Link the test suite into the right place in source tree.
ln -s %{_builddir}/spec .
rspec -Ilib spec
ruby -Ilib -e 'Dir.glob "./test/**/*_test.rb", &method(:require)'