Let's suppose you downloaded a source code folder, that contains an existing /debian/ folder as well as /debian/control file.

Let's suppose the package in question is not in Debian official repository, so apt-get build-dep cannot be used.

How to parse the Build-Depends: line?

For example, if the line would read Build-Depends: debhelper (>= 8), faketime, is there some tool control-parse debian/control build-depends that would echo debhelper faketime?

Especially when it's multi line?

Are there existing Debian tools or has one to write its own code to parse this?

3 Answers 3



Use modules from the libdpkg-perl (dpkg-checkbuilddeps uses those modules internally)

Add the following lines to print-build-deps and run print-build-deps at the source package root.

use strict;
use warnings;

use Dpkg::Control::Info;
use Dpkg::Deps;

my $control = Dpkg::Control::Info->new();
my $fields = $control->get_source();
my $build_depends = deps_parse($fields->{'Build-Depends'});
print deps_concat($build_depends) . "\n";

See also:

perldoc Dpkg::Control::Info
perldoc Dpkg::Deps


You can use mk-build-deps from devscripts:

apt-get install devscripts
apt-get install equivs
cd project-root # project-root contains debian/control
mk-build-deps -i

man mk-build-deps says:

mk-build-deps - build a package satisfying a package's build-dependencies
-i, --install
       Install the generated packages and its build-dependencies
  • This seems like a clean solution because it uses tools from the context, so it might be more robust. On recent Debian (at least) it needs packages devscripts and equivs, generate a temp package myproject-build-deps and installs it. This is nice if you're not intending to keep the build-time dependencies on your machine: just uninstall devscripts, equivs and myproject-build-deps. Jan 2, 2020 at 20:54

You could use dpkg-checkbuilddeps. The man page says

This program checks the installed packages in the system against the build dependencies and build conflicts listed in the control file. If any are not met, it displays them and exits with a nonzero return code.

For example:

faheem@orwell:/usr/local/src/julia/julia-0.3.2$ dpkg-checkbuilddeps
dpkg-checkbuilddeps: Unmet build dependencies: libopenblas-dev (>= 0.2.10-1~) libopenlibm-dev libopenspecfun-dev (>= 0.4~) patchelf python-sphinx-rtd-theme

However, you could also just try building the package, using (for example) debuild, e.g.

faheem@orwell:/usr/local/src/julia/julia-0.3.2$ debuild -uc -us
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package julia
dpkg-buildpackage: source version 0.3.2-1
dpkg-buildpackage: source changed by Sébastien Villemot <[email protected]>
 dpkg-source --before-build julia-0.3.2
dpkg-buildpackage: host architecture amd64
dpkg-checkbuilddeps: Unmet build dependencies: libopenblas-dev (>= 0.2.10-1~) libopenlibm-dev libopenspecfun-dev (>= 0.4~) patchelf python-sphinx-rtd-theme
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1357:
dpkg-buildpackage -rfakeroot -D -us -uc failed

Which gives the same information (since it uses dpkg-checkbuilddeps), but is a little noisier.

  • dpkg-checkbuilddeps outputs only unmet build dependencies. See my answer about parsing in common case.
    – Evgeny
    Jul 22, 2015 at 8:56

This Perl one-liner can be used to parse building dependencies from debian/control:

perl -ne 'next if /^#/; $p=(s/^Build-Depends:\s*/ / or (/^ / and $p)); s/,|\n|\([^)]+\)//mg; print if $p' < debian/control 

or runtime deps for built packages:

perl -ne 'next if /^#/; $p=(s/^Depends:\s*/ / or (/^ / and $p)); s/,|\n|\([^)]+\)//mg; print if $p' < debian/control 
  • Thanks to this one-lined, installing parsed dependencies is as easy as apt-get install $(perl -ne 'next if /^#/; $p=(s/^Build-Depends:\s*/ / or (/^ / and $p)); s/,|\n|\([^)]+\)//mg; print if $p' < debian/control)'. Just be aware that the dependencies will be marked as manually installed, so they will stick in the build environment. This has no importance in a throwaway build environment (chroot, docker), but if you build in your regular environment the build-time dependencies packages will remain. They can be quite big for some packages. Jan 2, 2020 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .