DH_RUBY(1) | DH_RUBY(1) |
dh_ruby - debhelper7 build system for Ruby software
dh_ruby [OPTIONS]
dh_ruby 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 packages.
dh_ruby can automatically run your tests against all supported Ruby versions, see the "FILES" section below.
See dh_ruby --help for details.
dh_ruby 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/, 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.
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:
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.
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 DH_RUBY_GEM_INSTALL_BLACKLIST_APPEND.
export DH_RUBY = --gem-install
If set to "all", all tests will be ignored during the package build.
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 not supported.
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.
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.
Directories cannot be blacklisted directly. To blacklist an entire directory, use a glob expression such as foo/*.
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). 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 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
If you want the upstream Makefile to be used, just make debian/dh_ruby.mk a symlink to ../Makefile.
If you want the upstream Rakefile to be used, just make debian/dh_ruby.rake a symlink to ../Rakefile.
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 <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/>.
2019-02-17 |