[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


let me say this first, Build-Depends are a good thing, the only problem I see
is that the use of Build-Depends is not well documented. At least I did not
find sufficient information easily when I wanted to use Build-Depends.

Recently I read in the weekly news, how to set up a chroot environment to
check for proper Build-Depends, that is an exellent thing (alltough I did
not test that yet). I, as a porter, see Build-Depends more from the practical
side, the build daemons, and probably most of the porters, have been using 
source depends before Build-Depends became part of the policy. So there is
allready a working scheme of source-depends (which does not differ much from
the Build-Depends), but I think most developers did not know about that.
I want to try to explain here, what we have been using before the great leap
(I did not invent source-depends, I am just using them, so please correct me
if I err. I am not very good at reading the policy and packaging manuals and
I find it very hard to extract the relevant information from them, thats 
why I am trying to summarize here what I think is important). In case its 
written down in a better way somewhere else, ignore me and point developers
to that place.

The (unasked) Build-Depends FAQ
Since Standard-Version 3.0.something (3.1.something?) every package
has to provide a Build-Depends line in the control file, if it needs
non-essential packages to build from source. The sense of this is (wild guess)
to make the life of the porters and build-daemons easier. 
Before the Build-Depends the build daemons were using a tool named sbuild and
a centralized source-dependencies database, which lists source-dependencies
for all packages which require special packages to build. The information in 
this database is identical to what Build-Depends should list. sbuild was 
improved to read the Build-Depends from the source file (to be exact from the 
*.dsc file) and install/remove packages as needed. Since the Build-Depends, as
provided by a package, override the source-dependencies, all packages, which 
have incorrect or incomplete Build-Depends, are very likely to fail 
autobuilding. So the porter or build-daemon maintainer files a bug. This 
involves a lot of boring work, which would not be necessary, if all 
maintainers, who want to use Build-Depends (or who are urged through bug 
reports) would know what the source-dependencies database lists for their 

Here is a link to a file hat I am using for autobuilding:


Dont worry about the m68k there. This file is updated daily.
You can copy the line for your package to the control file, just below the
Standards-Version is a good place.

Note: all packages that make use of debhelper, are required to list debhelper
in the Build-Depends. I guess no buildd will ever fail to build a package, if
debhelper is not listed, since the packages neede the most are probably 
installed permanetly on the build machine.
But debhelper is not listed in the build-essential packages AFAIK, so it has 
to be listed in the control file.

Note2: its important what the Build-Depends in the *.dsc file says, recently
I had a case where some magic was performed on the control file. Build-Depends
were correct in the control file, but unfortunatly incorrect in the *.dsc file,
so this package could not be autobuilt. sbuild looks at the *.dsc file, the 
control file does not exist at that time, its still in the debian diff...

Note3: another recent case, if you want your package to be linked against
a certain version of readline, ncurses, etc, you should put this version in
the Build-Depends. Its no use writing "recompiled for libxxx10" in the 
changelog, but saying in the control file any libxxx will do. You can even 
check for a certain version of, ie, debhelper, if your package needs a recent 
one to build. That way, the source will not even be unpacked, if this version 
is not available.

Note4: Dont worry too much, if you see a special source-dependency in the 
database, like *XXX-SOURCE or *LINUX21-HEADERS. Its most probably correct,
just use it as given there. If you want to discuss it, I think the 
source-dependencies maintainer will lend you an ear (not me, Roman? James?). 
And remember, the control file overides source-dependencies...

So please, every maintainer have a look at the source-dependencies for his 
packages, I am fed up with filing Build-Depends bugs.

Thank you for your attention,

Reply to: