Building a Debian package from a source tarball

For a person who has learnt Linux packaging on RPM-based systems in the first instance, it is annoying to find that there is no easy way (that I can discern) for building a binary Debian package directly from a source code tarball. I'm talking here about a source code tarball that is somehow 'packaging aware', i.e. it includes certain metadata that the packaging utility can use.

On RPM systems, one can tell people to download a generic myprog.tar.bz2 file and then run "rpmbuild -ta myprog.tar.bz2". However, there is no comparable option in the Debian world. The only requirement for the 'rpmbuild -ta' command is that the tarball contain a 'myprog.spec' file inside. RPM also has a spec file that includes support for a 'preprocessor' language, allowing a single .spec file to be crafted for a wide range of architectures; this again is a lack that makes distribution of Debian-capable tarballs impossible across a range of distros/releases.

This page presents a simple script, called dtar which tries to perform an equivalent task in the Debian world.

You can get dtar from our subversion repository, here: tools/dtar/dtar (see also the tools/dtar/README.txt).

dtar has been written as a general-purpose tool. Any source-code tarball that includes the 'debian/*' files should be able to be built directly with it.

This script needs you to first install the packages python-debian and python-apt from the Ubuntu repositories.

If you have any feedback about dtar, let me know.

Using dtar to build a binary .deb for ASCEND

To create a binary package for ASCEND, place the dtar script on your path, and obtain a source code tarball for ASCEND. Then run dtar. For example,

Invalid language.

You need to specify a language like this: <source lang="html">...</source>

Supported languages for syntax highlighting:

a4c, abap, abc, abnf, actionscript, ada, agda, alan, algol, ampl, amtrix, applescript, arc, arm, as400cl, ascend, asciidoc, asp, aspect, assembler, ats, autohotkey, autoit, avenue, awk, ballerina, bat, bbcode, bcpl, bibtex, biferno, bison, blitzbasic, bms, bnf, boo, c, carbon, ceylon, charmm, chill, chpl, clean, clearbasic, clipper, clojure, clp, cmake, cobol, coffeescript, coldfusion, conf, cpp2, critic, crk, crystal, cs_block_regex, csharp, css, d, dart, delphi, diff, dockerfile, dts, dylan, ebnf, ebnf2, eiffel, elixir, elm, email, erb, erlang, euphoria, exapunks, excel, express, factor, fame, fasm, felix, fish, fortran77, fortran90, frink, fsharp, fstab, fx, gambas, gdb, gdscript, go, graphviz, haml, hare, haskell, haxe, hcl, html, httpd, hugo, icon, idl, idlang, inc_luatex, informix, ini, innosetup, interlis, io, jam, jasmin, java, javascript, js_regex, json, jsp, jsx, julia, kotlin, ldif, less, lhs, lilypond, limbo, lindenscript, lisp, logtalk, lotos, lotus, lua, luban, makefile, maple, markdown, matlab, maya, mercury, meson, miranda, mod2, mod3, modelica, moon, ms, msl, mssql, mxml, n3, nasal, nbc, nemerle, netrexx, nginx, nice, nim, nix, nsis, nxc, oberon, objc, ocaml, octave, oorexx, org, os, oz, paradox, pas, pdf, perl, php, pike, pl1, plperl, plpython, pltcl, po, polygen, pony, pov, powershell, pro, progress, ps, psl, pure, purebasic, purescript, pyrex, python, q, qmake, qml, qu, r, rebol, rego, rexx, rnc, rpg, rpl, rst, ruby, rust, s, sam, sas, scad, scala, scilab, scss, shellscript, slim, small, smalltalk, sml, snmp, snobol, solidity, spec, spn, sql, squirrel, styl, svg, swift, sybase, tcl, tcsh, terraform, tex, toml, tsql, tsx, ttcn3, txt, typescript, upc, vala, vb, verilog, vhd, vimscript, vue, wat, whiley, wren, xml, xpp, yaiff, yaml, yaml_ansible, yang, zig, znn

Installing the resulting packages

To install your freshly-build ASCEND .deb packages, you can just

Invalid language.

You need to specify a language like this: <source lang="html">...</source>

Supported languages for syntax highlighting:

a4c, abap, abc, abnf, actionscript, ada, agda, alan, algol, ampl, amtrix, applescript, arc, arm, as400cl, ascend, asciidoc, asp, aspect, assembler, ats, autohotkey, autoit, avenue, awk, ballerina, bat, bbcode, bcpl, bibtex, biferno, bison, blitzbasic, bms, bnf, boo, c, carbon, ceylon, charmm, chill, chpl, clean, clearbasic, clipper, clojure, clp, cmake, cobol, coffeescript, coldfusion, conf, cpp2, critic, crk, crystal, cs_block_regex, csharp, css, d, dart, delphi, diff, dockerfile, dts, dylan, ebnf, ebnf2, eiffel, elixir, elm, email, erb, erlang, euphoria, exapunks, excel, express, factor, fame, fasm, felix, fish, fortran77, fortran90, frink, fsharp, fstab, fx, gambas, gdb, gdscript, go, graphviz, haml, hare, haskell, haxe, hcl, html, httpd, hugo, icon, idl, idlang, inc_luatex, informix, ini, innosetup, interlis, io, jam, jasmin, java, javascript, js_regex, json, jsp, jsx, julia, kotlin, ldif, less, lhs, lilypond, limbo, lindenscript, lisp, logtalk, lotos, lotus, lua, luban, makefile, maple, markdown, matlab, maya, mercury, meson, miranda, mod2, mod3, modelica, moon, ms, msl, mssql, mxml, n3, nasal, nbc, nemerle, netrexx, nginx, nice, nim, nix, nsis, nxc, oberon, objc, ocaml, octave, oorexx, org, os, oz, paradox, pas, pdf, perl, php, pike, pl1, plperl, plpython, pltcl, po, polygen, pony, pov, powershell, pro, progress, ps, psl, pure, purebasic, purescript, pyrex, python, q, qmake, qml, qu, r, rebol, rego, rexx, rnc, rpg, rpl, rst, ruby, rust, s, sam, sas, scad, scala, scilab, scss, shellscript, slim, small, smalltalk, sml, snmp, snobol, solidity, spec, spn, sql, squirrel, styl, svg, swift, sybase, tcl, tcsh, terraform, tex, toml, tsql, tsx, ttcn3, txt, typescript, upc, vala, vb, verilog, vhd, vimscript, vue, wat, whiley, wren, xml, xpp, yaiff, yaml, yaml_ansible, yang, zig, znn

ASCEND will then be accessible from your Applications menu, you will have syntax highlighting of ASCEND when you use GEDIT ('Text Editor' in Accessories menu), and you can double-click ASCEND model files to run them or edit them.

Problems and improvements

This script works pretty nicely for local building of a binary package. It means that you can install your package in such a way that you don't have to worry about remembering how to remove it later, and you don't have to remember complicated commands to build new versions of your package: you just need to (manually) update the 'debian/changelog' when you want to make a new release.

A problem still exists, which is that, when attempting to correct minor packaging problems when using packaging tools such as Ubuntu PPA, if you attempt to upload multiple different version of the same source code tarball using 'dput', your package will be rejected. So we need a way to build a package by somehow using a 'delta' between an old tarball and a new one.

A partial solution to this problem has been implemented, which is the option to allow all the debian/* files to be packaged in a separate 'debian metafiles tarball' (debian.tar.gz, as indicated in the suggested usage above). This approach works well with the OpenSUSE Build Service, but is cumbersome in general, because there is nothing to detect whether or not the tarball has changed and needs to be renumbered/renamed.

A better solution would be to somehow cache the last uploaded version of the tarball, and when a new tarball is encountered, to compare it and create a patch file as required. This is clearly processor-intensive, but the aim of this tool is to make packaging from tarballs easy, not to create the optimally efficient packaging system. The consequential practise from this packaging convention would be to only bump ASCEND version numbers *after* important changes have been made, because 'clean' tarballs will only be uploaded at a version number change.

It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.

The changelog text file embedded within the debian/* archive contains the email address of the person who packaged the file. This email address is also used to refer to the GPG key that must be used to successfully sign the resulting file. If that signature is not available, the package building process currently fails. Instead, a warning should be returned that unsigned packages were produced.