I am currently making a deb package with a collection of plain programs (e.g. shell scripts, python code, etc) and binaries (C code compiled with gcc). In order to meet the guidelines for package creation, I need to have a source package with the source code for the binaries. Because there is only one binary in my package, and the rest are all plain text programs, in what way should I make my source package?

To elaborate: Should my source package

  1. Have the DEBIAN directory and then just the path to the binary (replaced with the binaries' source code?
  2. Have the just the binaries' source code in one directory without the DEBIAN directory, and then gunzip that one directory?
  3. Have the exact same directory layout as the real package, just replacing the binaries with their own source code (e.g. bin/somebinary becomes bin/somebinary.c)?

    Any help would be greatly appreciated!

2 Answers 2


Use dh_make to make a template for the package. It'll ask you a few questions and create the required debian directory.

For a package that contains both binary executables and architecture-independent programs, you have two choices: make a single architecture-dependent binary package, or make an architecture-dependent binary package containing the binary executables and an architecture-independent binary package containing the scripts and other architecture-independent files. The main advantage of architecture-independent packages is to save space on distribution mirrors that store packages for multiple architectures. You also need to put the architecture-independent files in an architecture-independent package if you have a multiarch installation and you want to install the binaries for more than one architecture. Unless you care about this, make a single package, it's simpler. If you decide to make two packages, it's common to have a foo architecture-dependent package depending on foo-common or foo-data which is architecture-independent.

Your source package will contain everything that's needed to prepare the binary package(s), including the deb packaging scripts in the debian subdirectory, the sources of the compiled programs, and the various scripts. Keep the upstream archive as the source archive, don't reorganize or remove files to make the deb source package.

The Debhelper (dh) build automation tools will take care of assembling the directory structure of the binary package. There's no relation between the directory structure in the source tree and for the installed package. The default debian/rules is

        dh $@

If the commands are something other than ./configure && make && make install, add corresponding targets in debian/rules. For example, to pass options to ./configure:

        ./configure --with-foo

For installation of files, list files you need to copy in debian/PACKAGENAME.install, they'll be copied by dh_install. List directories to create in debian/PACKAGENAME.dirs (for dh_installdirs).

See the debhelper manual for all the steps that can be configured. There's automation for installing build output, man pages, fonts, shared libraries, perl modules, etc.

For more information, see:


First of all it's a very wide topic.You can use dpkg-buildpackge to build the source package from the sources.Because you explicitly mentioned that how your debian packaging should be, I am just going to write about it.

  • You should have a debian directory inside your source folder.
  • rules file inside the debian directory, you should overwrite some of the deb helper rules like auto configure or strip using deb helper keywords(For example using, override_dh_auto_configure: or override_dh_strip etc etc...)
  • You should have an package.install file specifying what should go where, For example if you generated an binary then you should mention the path of the binary where should it get installed or if you have any shared objects(.so) files.If you are using automake then it will be very easy.You can just mention it in Makefile.am saying where your binary or library should get installed.
  • You should have a control file used to mention the build dependencies and package dependencies.(The things which are required during your debian pakcage installation.)
  • A post installation script used to perform any operations/changes after installing your debian pakcage.(For example if you want to change the permission of a file after the installation or something else).
  • A changelog file having the description of changes on the package and the version number.

    If everything goes fine then dpkg-buildpackage should give you a package_arch_version.deb file.

As I said it's a very huge topic. It will just give you an idea how a debian package looks and what it will contain? You should cutomize those files according to your requirements.

You must log in to answer this question.