dh_ruby - debhelper7 build system for Ruby software
is a Debhelper 7 build system for Ruby software. It will
automatically build and install files contained in Ruby packages, trying to
work as close to Rubygems as possible but respecting Debian standards for Ruby
dh_ruby can automatically run your tests against all supported Ruby versions,
see the "FILES" section below.
See dh_ruby --help for details.
supports two different source package styles: single-binary
source packages, and multi-binary source packages.
The default layout is the single-binary
layout. This is the layout used
by most Ruby packages upstream, i.e. Ruby code in lib
programs in bin
/, etc. Packages imported from Rubygems using
will have this layout.
When using this layout, dh_ruby
will install files (Ruby code,
executables, gemspecs) to the first binary package
introduced support for the
layout. This layout should be used when you have a set of
different Ruby packages maintained upstream in a single VCS, and you decide
that you also want to maintain a single source package in Debian having the
different components as separate binary packages.
In this layout, the source package contains the separate components in
subdirectories where each of them will use the standard Ruby layout (
This layout does not support creating separate binary packages from the same
root directory. For those cases, see the documentation on
To indicate that you want to use a multi-binary layout, we have to 1) list your
multiple binary packages in debian/control
as usual, and add an
extra-field called X-DhRuby-Root
to each binary package stanza,
indicating which directory has to be used as the root for that binary package.
The corresponding source package should be layed out like this:
Important notes about multi-binary packages and the usage of
- If your package uses the multi-binary layout, it must
include ` gem2deb (>= 0.4.0~)` in Build-Depends.
Version 0.4.0 had a bug in the support for native extensions in
multi-binary packages, so if your package uses the multi-binary feature
and at least one of the sub-components has native extensions, you must use
` gem2deb (>= 0.4.1~)` in Build-Depends instead.
- The path indicated in X-DhRuby-Root, as you have
probably guessed by now, must be relative to the root of the source
- If any binary package declares a X-DhRuby-Root
field, all other binary packages that don't have one will be ignored by
- --clean, --configure, --build,
- Commands called by debhelper at various steps of the build
- Prints the supported Ruby versions.
- -h, --help
- Displays dh_ruby usage information.
- -v, --version
- Displays dh_ruby version information.
- This option indicates that the build should use the
gem command to install the files, instead of the homegrown
installer. Native packages will be installed to
/usr/lib/$ARCH/rubygems-integration/$RUBY_VERSION, while pure Ruby
packages will be installed to /usr/share/rubygems-integration/all.
There is an internal whitelist of directories from the source package that
need to be installed, but we can't possibly know all possibilities: if a
package needs to install a directory that is not automatically installed,
use DH_RUBY_GEM_INSTALL_WHITELIST_APPEND. If you want to exclude a
directory from being installed, use
- This option indicates that the build should use
setup.rb rather than the usual gem-based build. To take effect,
this option must come first !
- Use this variable to pass command line parameters to
dh_ruby. For example in debian/rules:
export DH_RUBY = --gem-install
- This is a space-separated list of tests that dh_ruby will
ignore during package build. The available test names are the names of all
supported Ruby versions (you can list them with `dh_ruby
If set to "all", all tests will be ignored during the package
- If this variable is defined (to anything), dh_ruby will
respect the directory informed by dh_auto_install(1), usually
debian/tmp. By default, gem2deb will install files to debian/
package, where package is the first binary package listed in
This is useful for multi-binary source packages that don't conform to the
supported layout (i.e. separate subdirectories each with lib/,
bin/ etc). Using this, all files will be installed to
debian/tmp, and you can them distribute them into separate binary
packages by using debian/$package.install files or explicit shell
calls in debian/rules.
Mixing DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR and multi-binary layout is
- Determines which file contain the gem specification with
package metadata. By default, dh_ruby will read metadata from a .gemspec
file in the root of source package directory. You can use this variable to
override that if you want to provide custom metadata for the Debian
In the case there are more than one .gemspec in the source package root, you
will need to use DH_RUBY_GEMSPEC to instruct dh_ruby about which
one to use.
- When using --gem-install, this variable adds files
to the list of files that need to be installed. Entries must be separated
by spaces, and can be either exact filenames, of glob expressions (e.g.
Directories cannot be added directly, only files. If you want to include an
entire directory, say foo, use a glob expression like foo/*.
Note that by default all top-level files are automatically blacklisted,
except VERSION* which is used by some packages. If you need a
top-level file to be installed, you need to whitelist it.
- When using --gem-install, this variable adds files to the
list of files that SHOULD NOT be installed. Entries must be separated by
spaces, and must be either specific filenames, or glob expressions (e.g.
Directories cannot be blacklisted directly. To blacklist an entire
directory, use a glob expression such as foo/*.
debian/ruby-tests.rake, debian/ ruby-tests.rb
- Theses files can be used to explicitly tell dh_ruby how to
run the tests in your package. When running the tests, dh_ruby will
automatically set RUBYLIB to include the appropriate directories where the
package files were installed in your package to make sure the tests use
them instead of the files in the source directory.
Your package can only contain at most one of these files.
debian/ ruby-test-files.yaml must contain a YAML document with a list
of test files to be run. If the package metadata contains an explicit list
of test files, gem2deb(1) will automatically generate this file for
you. Example from ruby-mime-types:
debian/ ruby-tests.rake can be used to run the tests with
rake(1). If you use this file, your package must Build-Depend on
the rake package. You can use anything you would use in a regular
Rakefile, but you must define a default task. gem2deb includes a utility
test task that makes it easier for you by creating a default task
Gem2Deb::Rake::TestTask.new do |t|
t.test_files = FileList['test/*_test.rb']
You can also use the equivalent RSpec task:
Gem2Deb::Rake::RSpecTask.new do |spec|
spec.pattern = './spec/**/*_spec.rb'
If debian/ ruby-tests.rb exists, it will be run with each supported
Ruby version, and must finish with a exit status of 0, otherwise
dh_ruby assumes the tests failed. A simple example:
require 'mypackage' # if 'mypackage.rb' or 'mypackage.so' was not installed properly, this will fail
class MyPackageTest < Test::Unit::TestCase
assert_equal 4, MyPackage.sum(2,2)
- If this file is present, dh_ruby will call make
passing it as the makefile during the build, in the clean,
build, and install steps, like this:
- clean: make -f debian/dh_ruby.mk clean
- build: make -f debian/dh_ruby.mk
- install: make -f debian/dh_ruby.mk install
If you want the upstream Makefile to be used, just make debian/dh_ruby.mk
a symlink to ../Makefile
- If this file is present, dh_ruby will call rake
passing it as the rakefile during the build, in the clean,
build, and install steps, like this:
- clean: rake -f debian/dh_ruby.rake clean
- build: rake -f debian/dh_ruby.rake
- install: rake -f debian/dh_ruby.rake install
If you want the upstream Rakefile to be used, just make
a symlink to ../Rakefile
- If this file exists, it will be used as the package
gemspec, regardless of metadata.yml and any *.gemspec that
exists in the upstream source. Using this is only advised on single-binary
source packages, and the behavior of this feature is undefined for
multi-binary source packages (see SOURCE PACKAGE LAYOUT
If debian/ gemspec is a symlink, it will first be expanded, and then
the symlink target will be used as a gemspec.
Hint: for packages with multiple gemspec, you can have debian/
gemspec as a symlink pointing to the one you want to use.
Copyright (c) 2011, Lucas Nussbaum <email@example.com>
This program is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program. If not, see <http://www.gnu.org/licenses/>.