Copyright 2003 Colin Walters. Permission is granted to copy, distribute and/or modify this document under the terms of the GPL.
2003-09-29
| Revision History | |
|---|---|
| Revision 2 | |
| Revision 1 | 2003-09-29 |
| First DocBook/XML version. | |
Table of Contents
The current generally accepted practice for creating new Debian packages is to run dh_make, which generates a bunch of files, the most important of which are debian/control, debian/copyright, and debian/rules. The first two are relatively straightforward.
But debian/rules is not. Debhelper was an enormous step forward in this area, greatly reducing redundant and incomprehensible code from the Debian package creation process. But it doesn't go far enough; the typical dh_make generated debian/rules is hundreds of lines, only some of which applies. In my experience with helping several people to learn Debian packaging, debian/rules was by far the hardest part for them to understand.
Moreover, this generated code will become stale with time, as the Debian policy changes. A few months ago the DEB_BUILD_OPTIONS variable dropped the debug flag in favor of noopt. But I gradually realized that since the code to check this variable was duplicated over hundreds (if not thousands) of dh_make generated source packages (and had possibly been modified), it would likely be years before most packages were updated. And there are many packages which predate DEB_BUILD_OPTIONS which don't even use it at all, when they easily could.
The Unix and hacker cultures in general have long looked down upon generated code, and for good reason. It is often hard to edit, and there is almost always no way to regenerate the code, but keep your local changes. Instead of generating code (like all the Microsoft tools tend to do), the Unix tradition is to create a metalanguage, a compiler, or some other form of abstraction.
CDBS is that abstraction. It's not the first attempt at abstracting the Debian build process; before Debhelper, many attempts came along and had only marginal success, if any. So now the question you're asking yourself is probably:
First of all, it is not monolithic (as opposed to e.g. debstd). CDBS is quite simply a set of Makefile fragments which can be included; if you don't want a particular part, you just don't include the Makefile fragment for it.
Second, CDBS does not attempt to supplant Debhelper (which has generally done an excellent job of the binary stage of Debian package building). CDBS can optionally use Debhelper to implement various parts of building a Debian package. This is the recommended mode of operation, actually. But some people may find debhelper doesn't work for them; if that's the case, you just don't include debhelper.mk, and you can do the work yourself.
Third, CDBS tries to make the common case easy. If you have a package which uses the GNU autotools and such, you can have a working build system simply by including about 2-3 Makefile fragments. No custom code required at all. Additionally, it has even higher-level Makefile fragments; for example, there are gnome.mk and kde.mk rule files which handle a number of common things required by GNOME and KDE packages.
Finally, CDBS (along with Debhelper) should make it much easier to effect systemwide changes. For example, if we later decide to switch our default i386 architecture to i486 (as we probably will), all I have to do is change autotools.mk, and the correct --host and --build will be passed to all ./configure invocations. Currently some packages have the DEB_HOST_ARCH boilerplate code in their debian/rules; many don't.
Another example: currently many packages use DocBook/XML, but since Debian doesn't have an XML catalog, we have to substitute the global identifiers for local system ones. I placed the code to do this in a docbook.mk rule file. But Debian will (hopefully!) eventually get an XML catalog. Once we do, to stop making these changes, all I have to do is remove the code from docbook.mk.
Some things done in CDBS could just as well go into a dh_foo program (for example, some of autotools.mk). Likewise, some dh_programs would probably do better as CDBS makefile fragments (dh_python comes to mind).
But CDBS' Makefile fragment orientation allows it to do things that Debhelper can't, or can't easily do. For example, CDBS automatically generates a ton of Makefile rules corresponding to package building. This saves a great deal of redundant code in debian/rules.
CDBS automatically creates build-arch and build-indep targets, and builds arch and indep packages under them. It also can cleanly affect a number of different parts of the build system (e.g. clean, configure, build), by simply including one Makefile fragment; doing this as a dh_foo would require inserting a call like dh_foo --clean, dh_foo --configure at each step. And doing things this way wouldn't allow future expansion; you'd have to change your code to say dh_foo --build if the foo helper wanted to modify the build process too.
So CDBS compliments Debhelper (or it can; again, CDBS does not require Debhelper).
In summary, I believe CDBS (typically combined with Debhelper) should be the future of Debian packaging. By reducing the complexity in each package, we make sweeping changes much easier. Debian has made several major transitions in the past, and we will in the future. It shouldn't be as painful as it has been. Moreover, CDBS makes creating simple packages very easy, as it should be.