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.