[ Please don't Cc: public replies to debian-devel me. ] Ben Collins: > All it does is included the Source-Depends field into the .dsc file. I don't understand perl, nor the dpkg guts, so I'll have to ask: What creates the Source-Depends field? I can't think of a way to create it automatically, so I guess it must be by hand. (That's good enough, I'm just checking.) After writing dbuild and running it a few times on slink, I have formed the following vision of source dependencies: Build-Depends: lists binary packages that need to be installed when the package is built. The dependencies should have versions, if there is a need for the version; otherwise, they should not. For example, any version of gcc would be good enough for most packages, but some versions of gcc may have a bug that causes a bug in the package being compiled, so the package needs to depend on a new version. As you say, dependencies on "base" build tools do not need to be listed. The exact list of such tools needs to be written, but IMHO includes C (cc) and C++ (c++) compilers and corresponding libraries (libc6-dev, and whateveritis for C++). The list can be worked on as we get experience with what people need. However, it might be that the list of exceptions is short, and we might be able to do without it completely. Source-Package-Depends: lists *source* packages that are needed to build the package. For example, a number of packages need the kernel source tree, and sometimes need specific versions of it. The names are not important to me. For a first version, we can do without Source-Package-Depends altogether and version numbers in Build-Depends, but they are needed in the long run. After an official version of dpkg-dev supports source dependencies, I will happily add support for them to dbuild. After things settle, it should be made policy that packages use the new headers.
Description: PGP signature