Translation(s): none

Contents

  1. Building with gem2deb
    1. Build the package
    2. Import your package to git
    3. Fine tune your package
    4. Build the deb from source repo
    5. Make your package lintian clean
    6. Validate copyright file
    7. Filing ITP bug
    8. Source Only Uploads
    9. Rails engines

Building with gem2deb

Note: Always verify the command has finished successfully and make sure there is no error before proceeding to next command.

You should setup environment variables to pass your name and email to build tools to avoid adding these manually every time.

Build the package

First you need install gem2deb 

apt-get install gem2deb

Create a build directory and go there 

mkdir -p ~/Build/ruby-packaging && cd $_

gem2deb devise

will run "gem fetch devise" to download the package. If there was no error, you should see a source package (*.dsc, *.orig.tar.gz, *.debian.tar.xz) and binary package (*.deb).

Note: we are using devise gem as an example in this document, if you are packaging another gem, use that gem name instead of devise.

  1. If you get an error that the Test failed, see ruby tests for hints to solve it.

  2. If you see "unmet build dependencies" error, install the build dependencies and rerun gem2deb. Install the build dependencies using apt and not using gem install.

Note 1: To fetch rails-assets-* gems, you need to provide a different gem source like this example

and then pass the downloaded .gem file to gem2deb

Note 2: If initial build failed and .dsc file was not created, you can create it from the package directory (ruby-<foo-version>). 

cd ruby-<foo-version>
dpkg-source -b .
cd ..

Import your package to git

Once you have the .dsc file, create a git repo from the source package (.dsc, .orig.tar.* and .debian.tar.*) 

gbp import-dsc --pristine-tar ruby-devise_<version>.dsc
cd ruby-devise
git tag -d debian/<version> # because the package is not ready yet

This will convert your source package to a debian source repository with most commonly used branch layout ie, master, upstream and pristine-tar branches.

Fine tune your package

Now you have to edit files inside debian sub-directory like

You will find such info at

Note 1: Read http://www.debian.org/doc/manuals/maint-guide/dreq.en.html to learn more about each file.

Note 2: Next two sections will give you some feedback on these files and what needs changing.

Build the deb from source repo

Once that is done build the package with 

dpkg-buildpackage

If you get an error that it could not be signed, ignore it for now.

Make your package lintian clean

And when it has finished check for lintian errors: 

lintian

If you get errors, you have to correct them. Then run dpkg-buildpackage again and test with lintian again.

Any changes you make to debian directory will be reflected in lintian output only if you build the package again with dpkg-buildpackage since lintian checkes the .changes file and not the debian directory in the source repo.

Make sure all copyright notices are added to debian/copyright file.

Note: There are two variants of MIT licenses (Expat or X11), use Expat when the text matches with that of license used in Expat project. See https://opensource.stackexchange.com/questions/8585/what-is-the-different-between-mit-and-x11-license-should-the-open-source-packag

Filing ITP bug

ITP stands for Intend to Package or telling the debian community that you are working on creating a new debian package for this software. See Teams/Ruby/Packaging/ITP for the steps.

Source Only Uploads

If your package got accepted in the archive (cleared NEW queue), you will need a SourceOnlyUpload to allow it to migrate to debian testing from debian unstable.

Rails engines

If your package has a app/assets or vendor/assets (if the gem name starts with rails-assets or ends at rails) then your package is very likely to be a rails engine. More about rails engines and Teams/Ruby/Packaging/RailsEngines has current recommended practices for packaging a rails engine.