11

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?

4

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 <sebastien@debian.org>
 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.

|improve this answer|||||
  • dpkg-checkbuilddeps outputs only unmet build dependencies. See my answer about parsing in common case. – Evgeny Vereshchagin Jul 22 '15 at 8:56
4

Parsing:

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.

#!/usr/bin/perl
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

Installation:

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
|improve this answer|||||
  • 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. – Stéphane Gourichon Jan 2 at 20:54
3

This Perl one-liner can be used to parse 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

perl -ne 'next if /^#/; $p=(s/^Depends:\s*/ / or (/^ / and $p)); s/,|\n|\([^)]+\)//mg; print if $p' < debian/control 
|improve this answer|||||
  • 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. – Stéphane Gourichon Jan 2 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.