Provided by: gem2deb_2.2.5_amd64 
NAME
dh_ruby - debhelper build system for Ruby software
SYNOPSIS
dh_ruby [OPTIONS]
DESCRIPTION
dh_ruby is a Debhelper 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 packages.
dh_ruby can automatically run your tests against all supported Ruby versions, see the
"FILES" section below.
See dh_ruby --help for details.
SOURCE PACKAGE LAYOUT
dh_ruby supports two different source package styles: single-binary source packages, and
multi-binary source packages.
Single-binary layout
The default layout is the single-binary layout. This is the layout used by most Ruby
packages upstream, i.e. Ruby code in lib/, executable programs in bin/, etc. Packages
imported from Rubygems using gem2deb(1) will have this layout.
When using this layout, dh_ruby will install files (Ruby code, executables, gemspecs) to
the first binary package listed in debian/control.
Multi-binary layout
gem2deb version 0.4.0 introduced support for the multi-binary 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 (lib/, bin/, etc).
This layout does not support creating separate binary packages from the same root
directory. For those cases, see the documentation on DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR
below.
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.
An example:
Source: mymultibinarypackage
[...]
Package: ruby-foo
X-DhRuby-Root: path/to/foo
[...]
Package: ruby-bar
X-DhRuby-Root: path/to/bar
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:
• 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 package.
• If any binary package declares a X-DhRuby-Root field, all other binary packages that
don't have one will be ignored by dh_ruby.
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 is an internal include list 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_INCLUDE. If you want to exclude a directory from being installed,
use DH_RUBY_GEM_INSTALL_EXCLUDE. Note that for using those variables, you need to
build depend on gem2deb (>= 1.6~).
COMPATIBILITY LEVELS
dh_ruby reuses the debhelper(7) compatibility levels for introducing behavior changes that
might be backwards-incompatible.
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 that 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.
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.
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
debian/ruby-test-files.yaml, 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:
---
- test/test_mime_type.rb
- test/test_mime_types.rb
debian/ruby-tests.rake can be used to run the tests with rake(1). 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
automatically. Example:
require 'gem2deb/rake/testtask'
Gem2Deb::Rake::TestTask.new do |t|
t.test_files = FileList['test/*_test.rb']
end
You can also use the equivalent RSpec task:
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
must finish with a 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 (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 will
be copied into under 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, e.g.:
debian/tests/assets/javascripts/application.js
debian/tests/assets/stylesheets/application.scss
In the above example, those files will be copied at 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.
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, just make debian/dh_ruby.mk a symlink to
../Makefile.
debian/dh_ruby.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
If you want the upstream Rakefile to be 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. 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 above).
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.
SEE ALSO
gem2deb(1)
COPYRIGHT AND AUTHORS
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/>.
2024-11-13 DH_RUBY(1)