Is there a way to automatically determine dependencies when setting up a dpkg control file?

Question

Most of the fields in a dpkg (Debian) control file are straightforward. The tricky one is determining the list of dependencies (Depends:). I was hoping that dpkg-gencontrol could do this for me by looking at the ldd output for the executables in the package directory. Perhaps it can, but I can't get it to work.

If this is what dpkg-gencontrol is for, the error I am getting is:

dpkg-gencontrol: error: syntax error in control_template at line 7: first block lacks a source field.

For reference, the command is dpkg-gencontrol -v1.1 -ccontrol_template -lchangelog -Pdebian. The control_template file contains this:

Package: my-package
Maintainer: Joe Coder <[email protected]>
Description: The my-package system
 A longer description that runs to the end of one line and then 
 extends to another line.
Priority: optional

If this is not what dpkg-gencontrol is for, does anyone have any suggestions as to what I can do, or advice on how to set up the dependencies list, ideally automatically?

Admittedly, inferring dependencies in a general way is probably a very difficult problem, especially if you extend the search to scripts and other programs. I am hoping that some tools exists that works most of the time.

Note that this is for internal distribution only. I am not building a package to go into a Linux distribution or even to be downloaded by the general public, so I am happy to bend/break standard rules if needed.

Answer 1

After some digging inspired by thiton's answer, and a whole lot of trial and error, I finally found a solution to my problem. It turns out that dpkg-gencontrol is not the tool to infer package dependencies from executables, dpkg-shlibdeps is. However, things need to be set up carefully for the two programs to help generate a package. Read on....

Running dpkg-shlibdeps -O <executable> results in a listing of the packages and versions that need to be installed for that executable to run. Perfect. Almost. Ideally dpkg-gencontrol could use this in its processing, which it claims to be able to do through its variable substitution feature.

To make this go smoothly, I had to create a directory structure that matches the expectation of the Debian packaging tools. It looks basically like this:

my_project_directory/
  main.c (or other source code, etc.)
  debian/
    changelog    (created by hand; see below)
    control      (this is basically a template, created by hand; see below)
    files        (created by dpkg-gencontrol)
    substvars    (created by dpkg-shlibdeps and used by dpkg-gencontrol)
    tmp/         (tmp is the root of the target system's filesystem)
      path/
        to/
          my/
            project/
              executable_1  (this will be installed at /path/to/my/project)
              executable_2  (this, too)
      var/
        www/
          index.php  (this will be installed at /var/www on target systems)
      DEBIAN/        (create this by hand)
        control      (created by dpkg-gencontrol and used in the final package)

Note that the Debian packaging tools preserve the owner and group of all files under debian/tmp/. Thus if you want files owned by root or some other user when installed, things get tricky. One option is to prepare the debian directory tree as root, and set owners as you like. If you prefer to not run as root, or are not allowed to, there is another way.

Create a script that calls chown, etc. to adjust ownerships as you like, with the last line being dpkg-deb -b debian/tmp . (which builds the .deb package, see below for an example). Run it through fakeroot, another Debian tool, like this: fakeroot ./fix_ownerships_and_build.sh. Fakeroot lets programs behave as if they were root, without actually changing things as root would do. It was created for just this scenario.

I looked into why dpkg-gencontrol was generating the "first block lacks a source field" error, even going so far as to reading its Perl source. As often happens, the error code is precise without providing enough context to know what to do: the control file really does need a field called "source", in its first (of two) blocks.

There are two kinds of Debian packages, source and binary. I thought I needed a binary one since I just want to put compiled executables into it, but I couldn't get that to work. I tried a source package, and added a source field to my control file. This got rid of the "first block lacks a source field" error, but led to another. Reading the documentation more closely, I realized that source packages need two "paragraphs" in their control files. Once I changed my control file to look like this, it began to work (almost):

Source: my-package
Maintainer: Joe Coder <[email protected]>

Package: my-package
Priority: optional
Architecture: amd64
Depends: ${shlibs:Depends}, apache2, php5
Description: The My-Package System
 A longer description that runs to the end of one line and then
 extends to another line.

What was still missing was a changelog file. This is a file to hold a history of releases of a package, with significant changes, version numbers, dates, and people responsible. I normally maintain such a thing in my own format, which I carefully converted to the exacting Debian changelog format. For some reason, the changelog was omitted from the final package, so I left my history file alone and used a placeholder instead, which looks like this:

my-package (1.0) unstable; urgency=low
  * placeholder changelog to satisfy dpkg-gencontrol
 -- Joe Coder <[email protected]>  Thu, 3 Nov 2011 16:49:00 -0700

The two leading spaces on the line with the * are essential, as is the single leading space on the line with the --, as are the two spaces between the email address and the date. And yes, the date needs to be that precise, timezone and all, even though it doesn't need to be accurate.

Putting everything together, with a debian directory tree set up as described above, the sequence of commands needed to build a package are as follows:

dpkg-shlibdeps debian/tmp/path/to/my/project/executable_1 \
               debian/tmp/path/to/my/project/executable_2
dpkg-gencontrol -v1.1  (or whatever version you are building)
fakeroot ./fix_ownerships_and_build.sh

where fix_ownerships_and_build.sh looks like this:

chown -R root:root debian/tmp/path  (or whatever user is appropriate)
chown -R www-data:www-data debian/tmp/var/www/*  (same goes here)
dpkg-deb -b debian/tmp .  (this leads to a nice my-package_1.1_amd64.deb file)

So that's it. Hopefully this answer will help others make progress faster than I did.