DH_RUBY(1)

📦
version 2.2.9 · 6 versions
, in ubuntu stonking

🌸 dh_ruby — DH_RUBY(1) 🌸

okay bestie, sit down, hydrate, because this is the little debhelper build system that handles Ruby software and she is booked and busy. ✨

💖 NAME 💖

dh_ruby — debhelper build system for Ruby software

✨ SYNOPSIS ✨

dh_ruby [OPTIONS]

🦋 DESCRIPTION 🦋

So <pink>dh_ruby</pink> is a Debhelper build system for Ruby software. She will automatically build and install the files living inside your Ruby packages, and the whole time she's trying to work as close to Rubygems as she possibly can — while still respecting Debian standards for Ruby packages. balance queen. 👑

She can also automatically run your tests against all supported Ruby versions — check the FILES section below for the deets.

For the full tea, run dh_ruby --help.

🌈 SOURCE PACKAGE LAYOUT 🌈

dh_ruby supports two different source package styles, and you gotta pick your lane:

  • single-binary source packages
  • multi-binary source packages

🎀 Single-binary layout

The default layout is the single-binary layout. It's the one most Ruby packages upstream already use — like, Ruby code in lib/, executable programs in bin/, you know the vibe. If a package got imported from Rubygems using gem2deb(1), bestie, it has this layout. fr fr.

When you're in this layout, dh_ruby installs files (Ruby code, executables, gemspecs) into the first binary package listed in debian/control. First come, first served, no cap.

💜 Multi-binary layout

gem2deb version 0.4.0 brought us the multi-binary layout and honestly? iconic. You want this one when you have a whole set of different Ruby packages maintained upstream in a single VCS, and you've decided you also want to maintain one source package in Debian that has the different components as separate binary packages.

In this layout, your source package holds the separate components in subdirectories, and each of those subdirectories uses the standard Ruby layout (lib/, bin/, etc). yes.

Heads up though: this layout does not support creating separate binary packages from the same root directory. For those cases, go read the docs on DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR further down.

To tell everyone you want the multi-binary layout, you gotta do two things:

  1. list your multiple binary packages in debian/control like usual, and
  2. add an extra-field called X-DhRuby-Root to each binary package stanza, saying which directory gets used as the root for that binary package.

An example (yes, exactly like this):

Source: mymultibinarypackage
[...]

Package: ruby-foo
X-DhRuby-Root: path/to/foo
[...]

Package: ruby-bar
X-DhRuby-Root: path/to/bar

And the corresponding source package should be layed out like this:

foo/
  foo.gemspec
  lib/
    foo.rb
  bin/foo
bar/
  bar.gemspec
  lib/
    bar.rb
  bin/
    bar

Important notes about multi-binary packages and the usage of X-DhRuby-Root — read these, bestie, I'm serious:

  • 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. not me warning you twice 💀

  • The path you put in X-DhRuby-Root — and you've probably already guessed this by now — must be relative to the root of the source package.
  • If any binary package declares an X-DhRuby-Root field, then all the other binary packages that don't have one will be ignored by dh_ruby. ghosted. 🙈

💅 OPTIONS 💅

  • --clean, --configure, --build, --test, --install — Commands called by debhelper at various steps of the build process.
  • --print-supported — Prints the supported Ruby versions.
  • -h, --help — Displays dh_ruby usage information.
  • -v, --version — Displays dh_ruby version information.
  • --gem-install — 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's an internal include list of directories from the source package that need to be installed, but like… we can't possibly know all the possibilities, bestie. So: if a package needs to install a directory that isn't automatically installed, use DH_RUBY_GEM_INSTALL_INCLUDE. And if you want to exclude a directory from being installed, use DH_RUBY_GEM_INSTALL_EXCLUDE. Note that to use those variables, you need to build depend on gem2deb (>= 1.6~). 💖

👑 COMPATIBILITY LEVELS 👑

dh_ruby reuses the debhelper(7) compatibility levels to introduce behavior changes that might be backwards-incompatible. it's giving "we grow together". 🌱

  • v14 — This level is still open for development; use with caution.

Changes from v13 are:

Packages are built and tested when executing the build target of debian/rules. The build is done as part of dh_auto_build, and the tests are run as part of dh_auto_test. The installation into debian/ is performed during the install target, i.e. during dh_auto_install. This means you can intercept the build between these steps using targets such execute_after_dh_auto_build, override_dh_auto_build, override_dh_auto_test, execute_before_dh_auto_install etc.

  • v13 — This is the recommended mode of operation.

This was the current compatibility level at the point where this mechanism was introduced. So even packages with compatibility levels lower than 13 use this mode.

In this this compatibility level, dh_ruby exhibits its classic behavior. In particular, packages are built, installed and tested during the dh_auto_install phase of the build process, i.e. when dpkg-buildpackage is invoking the install target of debian/rules.

🧚 SUBSTITUTION VARIABLES 🧚

  • ${ruby:Depends} — ${ruby:Depends} will expand to the runtime dependencies of the package. This is determined by taking the runtime dependencies from the Rubygems metadata, and then mapping them to Debian package names.

The relevant packages must be installed during the package build for the mapping to be successful (normally they should be hardcoded in the Build-Depends: field).

🌸 ENVIRONMENT VARIABLES 🌸

  • DH_RUBY — Use this variable to pass command line parameters to dh_ruby. For example in debian/rules:
export DH_RUBY = --gem-install
  • DH_RUBY_IGNORE_TESTS — 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 --print-supported).

If set to "all", all tests will be ignored during the package build. bye tests 👋

  • DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR — 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 debian/control.

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 (using X-DhRuby-Root:) is NOT SUPPORTED. do not do this. I am begging. 😭
  • DH_RUBY_GEMSPEC — 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 package.

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.

  • DH_RUBY_GEM_INSTALL_INCLUDE. — 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. *.txt, foo/*).

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 excluded, except VERSION* which is used by some packages. If you need a top-level file to be installed, you need to explicit list it as included.

  • DH_RUBY_GEM_INSTALL_EXCLUDE. — 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. *.txt).

Directories cannot be excluded directly. To exclude an entire directory, use a glob expression such as foo/*.

🌸 FILES — the debian/ folder tea, explained 🌸

okay bestie, this is the part where we go file by file through your debian/ directory and I tell you what each lil guy does. it's giving behind the scenes tour ✨

🎀 debian/ruby-test-files.yaml, debian/ruby-tests.rake, debian/ruby-tests.rb

These files are how you explicitly tell dh_ruby how to run the tests in your package. when it runs them, dh_ruby automatically sets RUBYLIB to include the appropriate directories where the package files got installed inside your package, so the tests use those files instead of the ones chilling in the source directory. no cap, that matters. 💅

your package can contain at most one of these files. one. uno. pick your fighter. 🙅♀️

debian/ruby-test-files.yaml must contain a YAML document with a list of test files to be run. and if the package metadata contains an explicit list of test files, gem2deb(1) will automatically generate this file for you. iconic. here's an example from ruby-mime-types:

---
- test/test_mime_type.rb
- test/test_mime_types.rb

debian/ruby-tests.rake lets you run the tests with rake(1). you can use anything you'd use in a regular Rakefile, but you must define a default task. gem2deb includes a utility test task that makes this easier for you by creating a default task automatically. example:

require 'gem2deb/rake/testtask'
Gem2Deb::Rake::TestTask.new do |t|
  t.test_files = FileList['test/*_test.rb']
end

and you can also use the equivalent RSpec task, because we love options:

require 'gem2deb/rake/spectask'
Gem2Deb::Rake::RSpecTask.new do |spec|
  spec.pattern = './spec/**/*_spec.rb'
end

if debian/ruby-tests.rb exists, it will be run with each supported Ruby version, and it must finish with an exit status of 0 — otherwise dh_ruby assumes the tests failed 😭. a simple example:

require 'test/unit'
require 'mypackage' # if 'mypackage.rb' or 'mypackage.so' was not installed properly, this will fail
class MyPackageTest < Test::Unit::TestCase
  def test_features
    assert_equal 4, MyPackage.sum(2,2)
  end
end

🦋 debian/tests/assets (a directory!)

for Rails assets packages (ruby-rails-assets-*), the presence of this directory will cause the Rails assets smoke test to be run. during the test run, this directory gets copied into app/ in a freshly created rails application, and bundle exec rake assets:precompile will be called. 🔥

debian/tests/assets should contain example usage of the given package, like:

debian/tests/assets/javascripts/application.js
debian/tests/assets/stylesheets/application.scss

in the example above, those files get copied to the following location in the test Rails app:

app/assets/javascripts/application.js
app/assets/stylesheets/application.scss
⚠️ Note: any dependencies needed to run this smoke test must be specified explicitly as package build dependencies. don't forget, bestie, or it will Not Work. 💀

💜 debian/dh_ruby.mk

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 instead, just make debian/dh_ruby.mk a symlink to ../Makefile. problem solved, slay. ✨

🌈 debian/dh_ruby.rake

exact same vibes but for rake. 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

and if you want the upstream Rakefile used, just make debian/dh_ruby.rake a symlink to ../Rakefile. 💅

⭐ debian/gemspec

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.

🚨 real talk: using this is only advised on single-binary source packages, and the behavior of this feature is undefined for multi-binary source packages (peep SOURCE PACKAGE LAYOUT above). undefined. behavior. do not test fate.

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 gemspecs, you can have debian/gemspec be a symlink pointing to the one you actually want to use. main character gemspec selection energy. 👑

👀 SEE ALSO

that's the whole list. go read it, iykyk. 🫶

Copyright (c) 2011, Lucas Nussbaum <lucas@debian.org>

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 version.

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/>.

okay that's the whole page, bestie, you made it to the end and that's iconic fr fr 🌟 this edition of DH_RUBY(1) landed on 2026-05-15, so if you're reading this any time after that, hi from the past, hope your tests all exit 0 on the first try 💅🎀🦋

📦 where this page comes from