Build-Depends
Hi,
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
packages.
Here is a link to a file hat I am using for autobuilding:
http://buildd.debian.org/andrea/m68k/source-dependencies-unstable.gz
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,
Christian.
Reply to: