RE: The project
For the benefit of non-Debian list readers, I want to explain a few things
about how Debian handles its source builds. Hamish, please correct me where
To accommodate the various platforms we support, and to provide a nominal
"chain-of-custody" for our software, all uploads involve a few components.
We have the binary package that was compiled for a particular architecture,
various administrative files telling the ftp archive where to put the file
and under what category, etc., a pristine source tarball from the upstream
creator of the software, a Debian source diff file, and a Debian source
control "dsc" file.
The diff file includes changes to the source to comply with Debian's
requirements (file naming, configuration file locations, etc.), plus a
directory containing the Debian build rules. The "Debian" directory
contains the build rules we use for the package. It also contains various
file dealing with licenses, manifests of documentation, example, and
configuration files, lists of directories needed by the package, etc. All
of the build rules are contained in a file called "rules", which is just a
When the Debian autobuilder (or a live porter) sees that a new package has
been uploaded, he/she/it can download the pristine source, the debian source
diff, and the *.dsc file. We have a home-grown tool that can be used to
extract the pristine souce, apply the source diff, and set appropriate
permissions. ("dpkg-source -x THEPACKAGE.dsc").
When the dpkg-source command finishes, we have a complete source tree ready
for the port maintainer to build. In most cases, it's as simple as issuing
a debian build command. In some cases, additional tweaking is necessary.
The point of all this is that it should be feasible to formalize the use of
this tool as something an end-user might be able to use. The "pristine
source + Debian diff" is very similar sounding (to me) to the BSD "source +
So, there are some issues:
1. Would a more "mainstream" BSD user really care about using the source to
build a package on his own system? If a binary package is available, I
suspect the average "user" will NOT care to compile software, unless there
is a substantial benefit in doing so (as in better performance, lower
resource usage, etc.) If so, then providing BSD binaries would be a good
2. Would a more "advanced" BSD user really care about having the source for
more than a handful of packages on her system? If the source is available
to anyone who cares for it, does the source need to be the "standard" method
3. If it is determined that having the raw source is very desirable for
certain packages, it should be possible to use the dpkg-source tool as a
basis for dpkg to handle the install and build of packages. Our
autobuilders (at Debian) do this already.