查看“Cdbs-doc”的源代码


== CDBS 文档 ==

原文出处：
* https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
* [http://blog.seety.org/yesterdaywork/ CDBS Documentation]

原文作者：
* Marc (Duck) Dequènes <duck@duckcorp.org>
* Arnaud (Rtp) Patard  <arnaud.patard@rtp-net.org>

授权许可：

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation.

版权说明：Copyright © 2004-2006 DuckCorp

翻译人员：

校正人员：

贡献人员：

适用版本：
文章状态：[[等待翻译]]
----



* Revision History

{|border="1" cellspacing="0"
|Revision 0.1.0||2005-04-03||First Public Release (for CDBS V0.4.27-3)
|-
|Revision 0.1.1||2005-06-07||Updated for CDBS V0.4.30 (perl class build dependency management, cdbs-edit-patch script)
|-
|Revision 0.1.2||2005-07-05||Added DEB_CONFIGURE_SCRIPT_ENV usage warning, fixed typo.
|-
|Revision 0.1.3||2005-09-16||Added info about dpatch extension requirements (additional include + include order). Added warning and workaround for DEB_AUTO_UPDATE_DEBIAN_CONTROL problems (see #311724).Fixed typos.
|-
|Revision 0.1.4||2005-10-02||Added info about quilt extension for patching sources.
|-
|Revision 0.2.0||2006-01-05||Added info about Ruby classes (Team & setup.rb). Reordered makefile and autotools class, and explaned relationship. Document extraordinary use of DEB_MAKE_ENVVARS in autotools class.
|-
|Revision 0.3.0||2006-04-23||Fixed typo (s/foo-date/foo-data/ reported by tioui). Warned of possible breakage if spaces in CURDIR (see #306941). Removed hacks in examples because of #300149, #284231 and #239128 / #341275. Updated for CDBS 0.4.37 (document DEB_MAKE_MAKEFILE, and special case when DEB_MAKE_CLEAN_TARGET can be empty + dh_installmime and dh_installcatalogs now called in debhelper class + s/DEB_ANT_TEST_TARGET/DEB_ANT_CHECK_TARGET/ which was a mistake in code, see #307813 + document DEB_CLEAN_EXCLUDE + default compat mode changed to 5 and DEB_DH_STRIP_ARGS usage too). Warn rules MUST come after CDBS includes (see #273835). Improved documentation of common build options.
|-
|Revision 0.4.0||2006-04-24||Updated for CDBS 0.4.39 (ability to use uuencoded patches + dh_installudev now called in debhelper class + KDE class improvements + 'config.*' left over autotools files not removed anymore + new DEB_DH_COMPAT_DISABLE variable + improved scrollkeeper and Python cleanup + updated common variables available in 'debian/rules'). Updated some examples accordingly. Improved part on compat. Improved fixes related to DEB_AUTO_UPDATE_DEBIAN_CONTROL problems.
|}

=== Foreword ===

This documentation describes what we succeeded to learn about CDBS usage, with as much details as possible.
Nevertheless, we are not using the whole set of available features ourselves, and some parts of this documentation were written for mere convinience and completeness.

Please note some examples in this documentation contain folded content which is necessary to keep the pages at a reasonnable width ; take care to unfold them when necessary before using them (eg: 'debian/control' content must not be folded or build will fail or result be incorrect).

If you find mistakes or missing information, feel free to contact Marc Dequènes (Duck) <duck@duckcorp.org>.

=== Chapter 1. Introduction ===

==== A bit of history ====

CDBS was written by Jeff Bailey and Colin Walters in march 2003, later joined by 4 other developers.

Basic information can be found on their project page.
In the package is provided a small set of examples (also available in the package here: /usr/share/doc/cdbs/examples/).

Since we were experimenting CDBS, it was obvious the lack of documention was preventing us from using it widely in our packages.
Thus we started to write some notes on CDBS usage, quickly growing to several pages.
This documentation is a revised version from the original DuckCorp Wiki page.

==== Why CDBS ? ====

CDBS is designed to simplify the maintainer's work so that they only need to think about packaging and not maintaining a 'debian/rules' file that keeps growing bigger and more complicated.
So CDBS can handle for you most of common rules and detect some parts of your configuration.

CDBS only uses simple makefile rules and is easily extensible using classes. Classes for handling autotools buildsys, applying patches to source, GNOME softwares, Python intall, and so on are available.

CDBS advantages :

* short, readable and efficient 'debian/rules'
* automates debhelper and autotools for you so you don't have to bother about this unpleasant and repetitive tasks
* maintainer can focus on real packaging problems because CDBS helps you but do not limit customization
* classes used in CDBS have been well tested so you are using error-proof rules and avoid dirty hacks to solve common problems
* switching to CDBS is easy
* can be used to generate Debian files (like 'debian/control' for GNOME Team Uploaders inclusion)
* CDBS is easily extendable
* It |70>< !!!

=== Chapter 2. First steps ===

==== Convert pkg to CDBS ====

Converting to CDBS is easy; A simple 'debian/rules' for a C/C++ software with no extra rules would be written as this :

<pre><nowiki>
#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
</nowiki></pre>

No, i'm not joking, this is sufficient to handle autotools management, like updating config.{guess|sub}, cleanup temp files after build and launch all common debhelper stuff.

Just use compat level 5 (or 4, a lower level may not work), create your <pkg>.install, <pkg>.info, etc as you usually do with dh_* scripts, and CDBS would call them if necessary, autodetecting a lot of things.
In case of a missing compat information, CDBS would create a 'debian/compat' file with compatibility level 5.
If you are using an obsolete DH_COMPAT variable in your 'debian/rules', you should get rid of it.
In this case, or in case you would like CDBS not to create a 'debian/compat' file, you can disable this feature by setting DEB_DH_COMPAT_DISABLE to a non-void value.

'''Important'''

If 'debian/control' management is activated (see below), build dependency on 'cdbs' is automatically added, if not, you will have to do it yourself.

'''Warning'''

Beware your working directory MUST NOT have spaces or CDBS would probably fail ; 

==== Basic settings and available variables ====

Remember you can get the pkg directory using the $(CURDIR) variable.

You can change common build parameters this way :

<pre><nowiki>
# where sources are
DEB_SRCDIR = $(CURDIR)/src
# in which directory to build
DEB_BUILDDIR = $(DEB_SRCDIR)/build
# in which directory to install the sofware
DEB_DESTDIR = $(CURDIR)/plop/
</nowiki></pre>

Some various variables you can use in 'debian/rules' :

Table 2.1. Common variables available in 'debian/rules'
{|border="1" cellspacing="0"
|DEB_SOURCE_PACKAGE||name of the source package
|-
|DEB_VERSION||full Debian version
|-
|DEB_NOEPOCH_VERSION||Debian version without epoch
|-
|DEB_UPSTREAM_VERSION||upstream version
|-
|DEB_ISNATIVE||non-empty if package is native
|-
| || 
|-
|DEB_ALL_PACKAGES||list of all binary packages
|-
|DEB_INDEP_PACKAGES||list of architecture independant binary packages
|-
|DEB_ARCH_PACKAGES||list of architecture dependant binary packages
|-
|DEB_PACKAGES||list of normal (non-udeb) binary packages
|-
|DEB_UDEB_PACKAGES||list of udeb binary packages, if any
|-
| || 
|-
|DEB_HOST_GNU_TYPE||GNU type on the host machine
|-
|DEB_HOST_GNU_SYSTEM||system part of GNU type on the host machine
|-
|DEB_HOST_GNU_CPU||CPU part of GNU type on the host machine
|-
|DEB_HOST_ARCH||Debian architecture name on the host machine
|-
|DEB_HOST_ARCH_CPU||CPU part of the Debian architecture name on the host machine
|-
|DEB_HOST_ARCH_OS||OS part of the Debian architecture name on the host machine
|-
| || 
|-
|DEB_BUILD_GNU_TYPE||GNU type for this build
|-
|DEB_BUILD_GNU_SYSTEM||system part of GNU type for this build
|-
|DEB_BUILD_GNU_CPU||CPU part of GNU type for this build
|-
|DEB_BUILD_ARCH||Debian architecture name for this build
|-
|DEB_BUILD_ARCH_CPU||CPU part of the Debian architecture name for this build
|-
|DEB_BUILD_ARCH_OS||OS part of the Debian architecture name for this build
|-
| || 
|-
|DEB_ARCH||old Debian architecture name
|-
| ||/!\ deprecated, only use to provide backward compatibility /!\
|-
| ||(see man dpkg-architecture for more information)
|}



==== Basic custom build rules ====
'''Warning'''
Beware to add rules after needed CDBS includes.

Suppose you want custom rules for the source package foo, creating foo (arch-dep) and foo-data (arch-indep), you simply need to add some lines to 'debian/rules'.


To add pre-configure actions :

<pre><nowiki>
makebuilddir/foo::
ln -s plop plop2
</nowiki></pre>


To add post-configure actions :

<pre><nowiki>
configure/foo::
sed -ri 's/PLOP/PLIP/' Makefile

configure/foo-data::
touch src/z.xml
</nowiki></pre>

/!\ in this case we are talking about package configuration and NOT about a configure script made with autotools.

To add post-build actions :

<pre><nowiki>
build/foo::
/bin/bash debian/scripts/toto.sh

build/foo-data::
$(MAKE) helpfiles
</nowiki></pre>

To add post-install actions :

<pre><nowiki>
install/foo::
cp debian/tmp/myfoocmd debian/foo/foocmd
find debian/foo/ -name "CVS" -depth -exec rm -rf {} \;

install/foo-data::
cp data/*.png debian/foo-data/usr/share/foo-data/images/
dh_stuff -m ipot -f plop.bz3 debian/foo-data/libexec/
</nowiki></pre>

To add post deb preparation actions :

<pre><nowiki>
binary/foo::
strip --remove-section=.comment --remove-section=.note --strip-unneeded \
debian/foo/usr/lib/foo/totoz.so
</nowiki></pre>

To add pre-clean actions :

<pre><nowiki>
cleanbuilddir/foo::
rm -f debian/fooman.1
</nowiki></pre>

==== Common Build Options ====

Default optimization is set using DEB_OPT_FLAG which default to "-O2" ; you can override it.
CFLAGS and CXXFLAGS are set to "-g -Wall $(DEB_OPT_FLAG)", CPPFLAGS is untouched from environment, but you can override these settings on a per-package basis using CFLAGS_<package>, CXXFLAGS_<package>, and CPPFLAGS_<package> variables.

DEB_BUILD_OPTIONS is a well known Debian environment variable, not a CDBS one, containing special build options (a comma-separated list of keywords).
CDBS does check DEB_BUILD_OPTIONS to take these options into account ; see details in each class.

==== Debhelper stuff ====
===== Not managing Debhelper =====

Yes, CDBS is doing almost everything for you :) .
Just add this line to the beginning of your 'debian/rules' file :

<code><nowiki>include /usr/share/cdbs/1/rules/debhelper.mk</nowiki></code>

CDBS debhelper rules handle the following dh_* scripts for each binary package automatically :

Table 2.2. Debhelper scripts commonly managed
{|border="1" cellspacing="0"
|dh_builddeb||dh_installcatalogs||dh_installdocs||dh_installlogrotate||dh_link
|-
|dh_clean||dh_installchangelogs||dh_installemacsen||dh_installman||dh_makeshlibs
|-
|dh_compress||dh_installcron||dh_installexamples||dh_installmenu||dh_md5sums
|-
|dh_fixperms||dh_installdeb||dh_installinfo||dh_installmime||dh_perl
|-
|dh_gencontrol||dh_installdebconf||dh_installinit||dh_installpam||dh_shlibdeps
|-
|dh_install||dh_installdirs||dh_installlogcheck||dh_installudev||dh_strip
|}

Other dh_* scripts can be handled in specific classes or may be called in custom rules.

'''Important'''
If 'debian/control' management is activated (see below), build dependency on 'debhelper' is automatically added, if not, you will have to do it yourself.

Having a versioned dependency on 'debhelper' is recommended as it will ensure people will use the version providing the necessary features (CDBS 'debian/control' management will do it).

===== Debhelper parameters =====

The following parameters allow debhelper calls customization while most common calls are still handled without writing any rule.
Some of them apply on all binary packaged, like DEB_INSTALL_DOCS_ALL, and some apply only to a specific package, like DEB_SHLIBDEPS_LIBRARY_<pkg> (where <pkg> is the name of the binary package).
Read the comments in '/usr/share/cdbs/1/rules/debhelper.mk' for a complete listing.
Some non-exhaustive examples follow.

To specify a tight dependency on a package containing shared libraries:

<pre><nowiki>
DEB_DH_MAKESHLIBS_ARGS_libfoo := -V"libfoo (>= 0.1.2-3)"
DEB_SHLIBDEPS_LIBRARY_arkrpg := libfoo
DEB_SHLIBDEPS_INCLUDE_arkrpg := debian/libfoo/usr/lib/
</nowiki></pre>

To install a changelog file with an uncommon name as 'ProjectChanges.txt.gz':

<pre><nowiki>
DEB_INSTALL_CHANGELOGS_ALL := ProjectChanges.txt
</nowiki></pre>

To avoid compressing files with '.py' extension :

<pre><nowiki>
DEB_COMPRESS_EXCLUDE := .py
</nowiki></pre>

To register a debug library package libfoo-dbg for libfoo (which needs unstripped '.so') in compat mode 4:

<pre><nowiki>
DEB_DH_STRIP_ARGS := --dbg-package=libfoo
</nowiki></pre>

In compat mode 5, CDBS automatically detect -dbg packages and pass the needed arguments to dh_strip ; DEB_DH_STRIP_ARGS can still be useful to pass additional parameters like excluded items (--exclude=<item>).

Perl-specific debhelper options (dh_perl call is always performed):

<pre><nowiki>
# Add a space-separated list of paths to search for perl modules
DEB_PERL_INCLUDE := /usr/lib/perl-z
# Like the above, but for the 'libperl-stuff' package
DEB_PERL_INCLUDE_libperl-stuff := /usr/lib/perl-plop

# Overrides options passed to dh_perl
DEB_DH_PERL_ARGS := -d
</nowiki></pre>

To avoid loosing temporary generated files in dh_clean processing (rarely useful):

<pre><nowiki>
# files containing these pattern would not be deleted
# (beware CDBS changelog has a typo while highlighting new DEB_CLEAN_EXCLUDE*S* feature)
DEB_CLEAN_EXCLUDE := precious keep
</nowiki></pre>

===== Debhelper custom build rules =====

CDBS debhelper rules also add more adequate build rules.

To add post deb preparation (including debhelper stuff) actions :

<pre><nowiki>
binary-install/foo::
chmod a+x debian/foo/usr/bin/pouet
</nowiki></pre>

To add post clean actions :

<pre><nowiki>
clean::
rm -rf plop.tmp
</nowiki></pre>

Several other rules exists, but we have not tested them :

* binary-strip/foo (called after stripping)
* binary-fixup/foo (called after gzipping and fixing permissions)
* binary-predeb (called just before creating .deb)

=== Chapter 3. Common tasks ===

==== Patching sources (using simple-patchsys) ====

First, patching sources directly is really BAD(tm), so you need a way to apply patches without touching any files.
These rules, inpired by the Dpatch system, are quite similar and powerful.
All you need is diff/patch knowledge, CDBS is doing the rest.

That's quite hard, so please listen carefully and prepare for examination.

First, add this line to your 'debian/rules' :

<code><nowiki>include /usr/share/cdbs/1/rules/simple-patchsys.mk</nowiki></code>

And then use it !

Create the directory 'debian/patches' and put your patches in it.
Files should be named so as to reflect in which order they have to be applied, and must finish with the '.patch' or '.diff' suffix.
The class would take care of patching before configure and unpatch after clean.
It is possible to use patch level 0 to 3, and CDBS would try them and use the right level automatically.
The system can handle compressed patch with additional '.gz' or '.bz2' suffix and uu-encoded patches with additional '.uu' suffix.

You can customize the directories where patches are searched, and the suffix like this :
(defaults are: .diff .diff.gz .diff.bz2 .diff.uu .patch .patch.gz .patch.bz2 .patch.uu)

<pre><nowiki>
DEB_PATCHDIRS := debian/mypatches
DEB_PATCH_SUFFIX := .plop
</nowiki></pre>

In case of errors when applying, for example 'debian/patches/01_hurd_ftbfs_pathmax.patch', you can read the log for this patch in 'debian/patches/01_hurd_ftbfs_pathmax.patch.level-0.log' ('0' because a level 0 patch).

'''Important'''
If 'debian/control' management is activated (see below), build dependency on 'patchutils' is automatically added, if not, you will have to do it yourself.

==== Patching sources (using dpatch) ====

To use Dpatch as an alternative to the CDBS included patch system, just add his line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/cdbs/1/rules/dpatch.mk
# needed to use the dpatch tools (like dpatch-edit-patch)
include /usr/share/dpatch/dpatch.make
</nowiki></pre>

Now you can use Dpatch as usual and CDBS would call it automatically.

'''Warning'''
You should include dpatch.mk AFTER autotools.mk or gnome.mk in order to have dpatch extension work correctly.

'''Important'''
If 'debian/control' management is activated (see below), build dependency on 'dpatch' and 'patchutils' is automatically added, if not, you will have to do it yourself.

==== Patching sources (using quilt) ====

To use Quilt as an alternative to the CDBS included patch system, just add his line to your 'debian/rules' :

<code><nowiki>include /usr/share/cdbs/1/rules/patchsys-quilt.mk</nowiki></code>

Now you can use Quilt as usual and CDBS would call it automatically.

'''Important'''

If 'debian/control' management is activated (see below), build dependency on 'quilt' and 'patchutils' is automatically added, if not, you will have to do it yourself.

==== Automatic tarball management ====

To use the CDBS tarball system, just add his line to your 'debian/rules', and specify the name of the top directory of the extracted tarball :

<pre><nowiki>
include /usr/share/cdbs/1/rules/tarball.mk

DEB_TAR_SRCDIR := foosoft
</nowiki></pre>

CDBS will recognize tarballs with the following extensions: .tar .tgz .tar.gz .tar.bz .tar.bz2 .zip

The tarball location is autodetected if in the top source directory, or can be specified :

<pre><nowiki>
DEB_TARBALL := $(CURDIR)/tarballdir/mygnustuff_beta-1.2.3.tar.gz
</nowiki></pre>

CDBS will handle automatic uncompression and cleanups, automagically set DEB_SRCDIR and DEB_BUILDDIR for you, and integrate well with other CDBS parts (like autotools class).

Moreover, if you want sources to be cleaned up from dirty SCM-specific dirs and file, just add this at the top of your 'debian/rules', before any include :

<pre><nowiki>
DEB_AUTO_CLEANUP_RCS := yes
</nowiki></pre>

'''Warning'''
The DEB_AUTO_CLEANUP_RCS feature has been removed for no good reason since version 0.4.39. Feel free to bugreport if you want it resurrected.

'''Important'''
If needed, and if 'debian/control' management is activated (see below), build dependency on 'bzip2' or 'unzip' is automatically added, if not, you will have to do it yourself.

=== Chapter 4. Advanced customisation ===

==== 'debian/control' management ====
'''Caution'''

Automatic 'debian/control' generation using any tool is permitted into Debian as long as it is triggered manually by the developer and the latter checks the result carefully.

Autogenerating 'debian/control' without any human intervention could be harmful in some ways detailed in #311724.
This is not allowed in Debian.

We then urge you to avoid using DEB_AUTO_UPDATE_DEBIAN_CONTROL directly and instead invoke the autogeneration rules manually after you modified 'debian/control.in' (this way users or buildds wouldn't have different Build-Depends when building, avoiding many problems). Do not forget to proofread the result before any upload.

Manual 'debian/control' regeneration:

<pre><nowiki>
DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes fakeroot debian/rules clean
</nowiki></pre>

This feature allow :

** CDBS to automatically manage some build-related Build-Depends automatically
** use of embedded shell commands
** use of CPU and System criterias to specify architecture (EXPERIMENTAL)

Build-related Build-Depends are dependencies introduced by the use of certain CDBS features, or autodetected needs.

Embedded shell commands allows including hacks like :

<pre><nowiki>
Build-Depends: libgpm-dev [`type-handling any linux-gnu`]
</nowiki></pre>

CPU and System criterias implements support for Cpu/System fields, as a replacement for the Architecture field (which is to be implemented in dpkg in the long term, but still EXPERIMENTAL).
Here is an exemple, before :

<pre><nowiki>
Architecture: all
</nowiki></pre>

and after :

<pre><nowiki>
Cpu: all
System: all
</nowiki></pre>

If these fields are used, it is also possible to include special tags to easily take advantage of the 'type-handling' tool, like in this example :

<pre><nowiki>
Build-Depends: @cdbs@, procps [system: linux], plop [cpu: s390]
</nowiki></pre>


(look at the 'type-handling' package documentation, for more information)

Here is the recipe :

* Rename 'debian/control' into 'debian/control.in'.
* Replace cdbs / debhelper / ... Build-Depends with @cdbs@ in your 'debian/control.in' like this :
<pre><nowiki>
Build-Depends-Indep: @cdbs@, python-dev (>= 2.3), python-soya (>= 0.9), \
python-soya (<< 0.10), python-openal(>= 0.1.4-4), gettext
</nowiki></pre>
* Then manually (re)generate 'debian/control' as explained above (see the caution part).

==== Using the Makefile class ====

This class is for the guys who only have a Makefile (no autotools available) to build the program. You only need to have four rules in the Makefile:

* one for cleaning the build directory (i.e. mrproper)
* one for building your software (i.e. myprog)
* one for checking if the software is working properly (i.e. check)
* one for installing your software (i.e. install)

To be honest, the install rules is not a must-have, but it always helps a lot when you've got it.

The first operation, is to write the debian/rules. First, we add the include lines:

<pre><nowiki>
include /usr/share/cdbs/1/class/makefile.mk
</nowiki></pre>

Now, it remains to tell cdbs the name of our four Makefile rules. For the previous examples it gives:

<pre><nowiki>
DEB_MAKE_CLEAN_TARGET    := mrproper
# if you detect authors's loss of sanity, tell CDBS not to try running the nonexistent clean rule, and do the job yourself in 'debian/rules'
DEB_MAKE_CLEAN_TARGET    :=
DEB_MAKE_BUILD_TARGET    := myprog
DEB_MAKE_INSTALL_TARGET  := install DESTDIR=$(CURDIR)/debian/tmp/
# no check for this software
DEB_MAKE_CHECK_TARGET :=

# allow changing the makefile filename in case of emergency exotic practices
DEB_MAKE_MAKEFILE        := MaKeFiLe
# example when changing environnement variables is necessary :
DEB_MAKE_ENVVARS    := CFLAGS="-fomit-frame-pointer"
</nowiki></pre>

DEB_BUILD_OPTIONS is checked for the following options :

* noopt: use -O0 instead of -O2
* nocheck: skip the check rule

If your Makefile doesn't support the DESTDIR variable, take a look in it and find the variable responsible for setting installation directory. If you don't find some variable to do this, you'll have to patch the file...

That's all :)

==== Using the Autotools class ====

This class is able to use configure scripts and makefiles generated with autotools (and possibly libtool).
All rules are called automatically and clean rules to remove generated files during build are also added.
This class in fact improves the makefile class to support autotools features and provide good defaults.

To use it, just add this line to your 'debian/rules'

<pre><nowiki>
include /usr/share/cdbs/1/class/autotools.mk
</nowiki></pre>

CDBS automatically handles common flags to pass to the configure script, but it is possible to give some extra parameters :

<pre><nowiki>
DEB_CONFIGURE_EXTRA_FLAGS := --with-ipv6 --with-foo
</nowiki></pre>

If the build system uses non-standard configure options you can override CDBS default behavior :
<pre><nowiki>
COMMON_CONFIGURE_FLAGS := --program-dir=/usr
</nowiki></pre>

(notice that DEB_CONFIGURE_EXTRA_FLAGS would still be appended)

If some specific environnement variables need to be setup, use :
<pre><nowiki>
DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS=" -Wl,-z,defs -Wl,-O1"
</nowiki></pre>

'''Warning'''

Prefer use of += instead of := not to override other environment variables (like CC / CXX / ...) defined in the CDBS default.

CDBS will automatically update 'config.sub', 'config.guess', and 'config.rpath' before build and restore the old ones at clean stage (even if using the tarball system).
If needed, and if 'debian/control' management is activated, 'autotools-dev' and/or 'gnulib' will then be automatically added to the build dependencies (needed to find updated versions of the files).

If the program does not use the top source directory to store autoconf files, you can teach CDBS where it is to be found :

<pre><nowiki>
DEB_AC_AUX_DIR = $(DEB_SRCDIR)/autoconf
</nowiki></pre>

CDBS can be asked to update libtool, autoconf, and automake files, but this behavior is likely to break the build system and is '''STRONGLY''' discouraged.
Nevertheless, if you still want this feature, set the following variables :

* DEB_AUTO_UPDATE_LIBTOOL
* DEB_AUTO_UPDATE_AUTOCONF
* DEB_AUTO_UPDATE_AUTOMAKE

(corresponding build dependencies will automatically be added)

The following make parameters can be overridden :

<pre><nowiki>
# these are the defaults CDBS provides
DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR)
DEB_MAKE_CLEAN_TARGET := distclean
DEB_MAKE_CHECK_TARGET :=

# example to work around dirty makefile
DEB_MAKE_INSTALL_TARGET := install prefix=$(CURDIR)/debian/tmp/usr

# example with unexistant install rule for make
DEB_MAKE_INSTALL_TARGET :=

# example to activate check rule
DEB_MAKE_CHECK_TARGET := check

# overriding make-only environnement variables :
# (should never be necessary in a clean build system)
# (example borrowed from the bioapi package)
DEB_MAKE_ENVVARS    := "SKIPCONFIG=true"
</nowiki></pre>

DEB_BUILD_OPTIONS is checked for the following options :

* noopt: use -O0 instead of -O2
* nocheck: skip the check rule

If you are using CDBS version < 0.4.39, it automatically cleans autotools files generated during build ('config.cache', 'config.log', and 'config.status').
Since version 0.4.39, CDBS leave them all considering it is not his job to correct an upstream buildsys misbehavior (but you may remove them in the 'clean' rule if necessary before you get the issue solved by authors).

==== Using the Perl class ====

This class can manage standard perl build and install with MakaMaker method.

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/cdbs/1/class/perlmodule.mk
</nowiki></pre>

Optionally, it can take care of using dh_perl, depending the debhelper class is declared before the perl class or not.

Install path defaults to '<first_pkg>/usr' where <first_pkg> is the first package in 'debian/control'.

You can customize build options like this :

<pre><nowiki>
# change MakeMaker defaults (should never be usefull)
DEB_MAKE_BUILD_TARGET := build-all
DEB_MAKE_CLEAN_TARGET := realclean
DEB_MAKE_CHECK_TARGET :=
DEB_MAKE_INSTALL_TARGET := install PREFIX=debian/stuff

# add custom MakeMaker options
DEB_MAKEMAKER_USER_FLAGS := --with-ipv6
</nowiki></pre>

Common makefile or general options can still be overrided: DEB_MAKE_ENVVARS, DEB_BUILDDIR (must match DEB_SRCDIR for Perl)

Have a look at Perl-specific debhelper options described above.

'''Important'''

If 'debian/control' management is activated (see below), build dependency on 'perl' is automatically added, if not, you will have to do it yourself.

==== Using the Python class ====

This class can manage common Python builds using 'distutils' automatically.

This class is compatible with both old and new Python policy. It provides a similar interface for both to allow easy migration to the new policy. Documentation for the old policy is kept to allow understanding of packages from pre-Etch releases, backports, and non-official packages.

===== New Python policy =====

With the new policy all versionned packages (python<ver>-<app>) are collapsed into a single package (python-<app>).
The class is able to move python scripts and .so files in the new locations automatically.
You can use the auto control file generation feature to ensure your Build-Depends are set correctly for the new needed tools.

To use this class, add these lines to your 'debian/rules' :

<pre><nowiki>
# select the python system you want to use : pysupport or pycentral
# (this MUST be done before including the class)
DEB_PYTHON_SYSTEM = pysupport
include /usr/share/cdbs/1/class/python-distutils.mk
</nowiki></pre>

Optionally, it can take care of using dh_python, and dh_pysupport or dh_pycentral,
if the debhelper class is declared before the python class (which is highly recommanded).

You can customize build options like this :

<pre><nowiki>

# package holding the collapsed content of all supported versions
# CDBS defaults to the first non -doc/-dev/-common package listed in 'debian/control"
DEB_PYTHON_MODULE_PACKAGE = mypyapp

# list of private modules private directoris (needed to automatically handle bytecompilation)
DEB_PYTHON_PRIVATE_MODULES_DIRS = /usr/share/mypyapp/my-pv-module


# change the Python build script name (default is 'setup.py')
DEB_PYTHON_SETUP_CMD := install.py

# clean options for the Python build script
DEB_PYTHON_CLEAN_ARGS = -all

# build options for the Python build script
DEB_PYTHON_BUILD_ARGS = --build-base="$(DEB_BUILDDIR)/specific-build-dir"

# common additional install options for all binary packages
#   ('--root' option is always set)
DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile --optimize --force


# Please don't use DEB_PYTHON_COMPILE_VERSION and DEB_PYTHON_VERSIONS
# anymore, their are not used by the class anymore
</nowiki></pre>

You may use some read-only (meaning you MUST NOT alter them) variables in your 'debian/rules' :

* $(cdbs_python_support_path): path where are installed the archall part of the selected package (defined only for python-support method)
* $(cdbs_python_module_arch): architecture of the selected package (used to detect if a module, thus archall, or an extension)
* $(cdbs_python_current_version): current python version number (defined only if selected package is a module)
* $(cdbs_python_build_versions): list of space separated version numbers for which the selected module/extension is gonna be built

Complete 'debian/rules' example using python-support for a module (editobj):

<pre><nowiki>
#!/usr/bin/make -f
# -*- mode: makefile; coding: utf-8 -*-

include /usr/share/cdbs/1/rules/debhelper.mk
DEB_PYTHON_SYSTEM = pysupport
include /usr/share/cdbs/1/class/python-distutils.mk
include /usr/share/cdbs/1/rules/patchsys-quilt.mk


DEB_COMPRESS_EXCLUDE := .py


install/$(DEB_PYTHON_MODULE_PACKAGE)::
mv debian/$(DEB_PYTHON_MODULE_PACKAGE)/usr/lib/python*/site-packages/editobj/icons \
debian/$(DEB_PYTHON_MODULE_PACKAGE)/usr/share/$(DEB_PYTHON_MODULE_PACKAGE)
rm -rf debian/$(DEB_PYTHON_MODULE_PACKAGE)/usr/lib

binary-install/$(DEB_PYTHON_MODULE_PACKAGE)::
find debian/$(DEB_PYTHON_MODULE_PACKAGE)/usr/share/ -type f -exec chmod -R a-x {} \;
echo "2.3-" >debian/$(DEB_PYTHON_MODULE_PACKAGE)/$(cdbs_python_support_path)/.version
</nowiki></pre>

===== Old Python policy =====

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/cdbs/1/class/python-distutils.mk
</nowiki></pre>

Optionally, it can take care of using dh_python, if the debhelper class is declared before the python class
(which is highly recommanded).

Most Python packages are architecture all, and then don't need being build for multiple Python versions ; your package should then be called 'python-<foo>' and CDBS would automatically use the current Debian Python version to build it.
If your package contains a compiled part or a binding to an external lib, then you will have packages named 'python2.3-<foo>', 'python2.4-<foo>', and so on, depending on ${python:Depends} (and perhaps other packages), then CDBS would automatically build each package with the corresponding Python version. In this case, don't forget to add a 'python-<foo>' convenience dummy package depending on the current Debian Python version.

You can customize build options like this :

<pre><nowiki>
# force using a specific Python version for build
# (should not be necessary)
DEB_PYTHON_COMPILE_VERSION := 2.3

# change the Python build script name (default is 'setup.py')
DEB_PYTHON_SETUP_CMD := install.py

# clean options for the Python build script
DEB_PYTHON_CLEAN_ARGS = -all

# build options for the Python build script
DEB_PYTHON_BUILD_ARGS = --build-base="$(DEB_BUILDDIR)/specific-build-dir"

# common additional install options for all binary packages
#   ('--root' option is always set)
DEB_PYTHON_INSTALL_ARGS_ALL = --no-compile --optimize --force

# specific additional install options for binary package 'foo'
#   ('--root' option is always set)
DEB_PYTHON_INSTALL_ARGS_foo := --root=debian/foo-install-dir/
</nowiki></pre>

==== Using the Ruby setup.rb class ====

This class can manage common setup.rb installer automatically.

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/ruby-pkg-tools/1/class/ruby-setup-rb.mk
</nowiki></pre>

Optionally, it can take care of using dh_rdoc, to generate and install Rdoc documentation, depending the debhelper class is declared before the ruby setup.rb class or not.

Most ruby packages are architecture all, and then don't need being build for multiple ruby versions ; your package should then be called 'lib<foo>-ruby' or '<foo>' and CDBS would automatically use the current Debian ruby version to build it.
If your package contains a compiled part or a binding to an external lib, then you will have packages named 'lib<foo>-ruby1.6', 'lib<foo>-ruby1.8', and so on, then CDBS would automatically build each package with the corresponding ruby version. In this case, don't forget to add a 'lib<foo>-ruby' convenience dummy package depending on the current Debian ruby version.
If you have documentation you want split into a separate package, then call it 'lib<foo>-ruby-doc'. If this is Rdoc documentation, you may want to include the debhelper class, as explained before, to have it generated and installed automagically.


You can customize build options like this :

<pre><nowiki>
# force using a specific ruby version for build
# (should not be necessary)
DEB_RUBY_VERSIONS := 1.9

# use ancestor
DEB_RUBY_SETUP_CMD := install.rb

# config options for the ruby build script
# (older setup.rb used --site-ruby instead of --siteruby)
DEB_RUBY_CONFIG_ARGS = --site-ruby=/usr/lib/ruby/1.9-beta
</nowiki></pre>

==== Using the Debian Ruby Extras Team class ====

If you are part of the Ruby Extras Team, or having the Team as Uploaders, and you feel bored maintaining the list of developers, this class is made for you.

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/ruby-pkg-tools/1/rules/uploaders.mk
</nowiki></pre>

Rename your 'debian/control' file to 'debian/control.in' and run the clean rule (./debian/rules clean) to regenerate the 'debian/control' file, replacing the '@RUBY_TEAM@' tag with the list of developers automatically.

==== Using the GNOME class ====

This class adds a make environnement variable :    GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL = 1
(''This is necessary because the Gconf schemas have to be registered at install time.
In the case of packaging, this registration cannot be done when building the package, so this variable disable schema registration in 'make install'.
This procedure if defered until gconftool-2 is called in 'debian/postinst' to register them, and in 'debian/prerm' to unregister them.
The dh_gconf script is able to add the right rules automatically for you.'')

It can handle the following dh_* scripts automagically :

Table 4.1. Debhelper scripts managed by the GNOME class
{|border="1" cellspacing="0"
|dh_desktop||dh_gconf||dh_scrollkeeper
|}

Moreover it adds some more clean rules to remove:

** intltool generated files
** scrollkeeper generated files (left over '.omf.out' files in 'doc' and 'help' directories)

To use it, just add this line to your 'debian/rules', after the debhelper class include :

<pre><nowiki>
include /usr/share/cdbs/1/class/gnome.mk
</nowiki></pre>

For more information on GNOME specific packaging rules, look at the Debian GNOME packaging policy.

==== Using the Debian GNOME Team class ====

If you are part of the GNOME Team, or having the Team as Uploaders, and you feel bored maintaining the list of developers, this class is made for you.

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk
</nowiki></pre>

Rename your 'debian/control' file to 'debian/control.in' and run the clean rule (./debian/rules clean) to regenerate the 'debian/control' file, replacing the '@GNOME_TEAM@' tag with the list of developers automatically.

'''Warning'''

If you are using the 'debian/control' file management described below, please note this class will override this feature To cope with this problem, allowing at least Build-Depends handling, use the following work-arround (until it is solved in a proper way) :

<pre><nowiki>
# deactivate 'debian/control' file management
#DEB_AUTO_UPDATE_DEBIAN_CONTROL := yes

# ...
# includes and other stuff
# ...

clean::
sed -i "s/@cdbs@/$(CDBS_BUILD_DEPENDS)/g" debian/control
# other clean stuff
</nowiki></pre>


==== Using the KDE class ====

To use this class, add this line to your 'debian/rules' file :

<pre><nowiki>
include /usr/share/cdbs/1/class/kde.mk
</nowiki></pre>

CDBS automatically exports the following variables with the right value :

* kde_cgidir (/usr/lib/cgi-bin)
* kde_confdir (/etc/kde3)
* kde_htmldir (/usr/share/doc/kde/HTML)

DEB_BUILDDIR, DEB_AC_AUX_DIR and DEB_CONFIGURE_INCLUDEDIR are set to KDE defaults.

The following files are excluded from compression :

* .dcl
* .docbook
* -license
* .tag
* .sty
* .el

(take care of them if you override the DEB_COMPRESS_EXCLUDE variable)

It can handle configure options specific to KDE (not forgeting disabling rpath and activating xinerama), set the correct autotools directory, and launch make rules adequately.

You can enable APIDOX build by setting the DEB_KDE_APIDOX variable to a non-void value.

you can enable the final mode build by setting DEB_KDE_ENABLE_FINAL variable to a non-void value.

DEB_BUILD_OPTIONS is checked for the following options :

** noopt: disable optimisations (and KDE final mode, overriding DEB_KDE_ENABLE_FINAL)
** nostrip: enable KDE debug (and disable KDE final mode, overriding DEB_KDE_ENABLE_FINAL)

You can prepare the build using the 'buildprep' convenience target: fakeroot debian/rules buildprep (which is in fact calling the 'dist' target of 'admin/Makefile.common').

==== Using the Ant class ====

(Ant is a java-based build tool)

To use this class, add this include to your 'debian/rules' and set the following variables :

<pre><nowiki>
include /usr/share/cdbs/1/class/ant.mk

# Set either a single (JAVA_HOME) or multiple (JAVA_HOME_DIRS) java locations
JAVA_HOME := /usr/lib/kaffe
# or set JAVACMD if you don't use default '<JAVA_HOME>/bin/java' path
#JAVACMD := /usr/bin/java

# Set Ant location
ANT_HOME := /usr/share/ant-cvs
</nowiki></pre>


You may add additional JARs like in the following example :

<pre><nowiki>
# list of additional JAR files ('.jar' extension may be omited)
#   (path must be absolute of relative to '/usr/share/java')
DEB_JARS := /usr/lib/java-bonus/ldap-connector adml-adapter.jar
</nowiki></pre>

The property file defaults to 'debian/ant.properties'.

You can provide additional JVM arguments using ANT_OPTS. You can provide as well additional Ant command line arguments using ANT_ARGS (global) and/or ANT_ARGS_<pkg> (for package <pkg>), thus overriding the settings in 'build.xml' and the property file.

CDBS will build and clean using defaults target from 'build.xml'. To override these rules, or run the install / check rules, set the following variables to your needs :

<pre><nowiki>
# override build and clean target
DEB_ANT_BUILD_TARGET = makeitrule
DEB_ANT_CLEAN_TARGET = super-clean
# i want install and test rules to be run
DEB_ANT_INSTALL_TARGET = install-all
DEB_ANT_CHECK_TARGET = check
</nowiki></pre>

DEB_BUILD_OPTIONS is checked for the following options :

** noopt: set 'compile.optimize' Ant option to false

You should be able to fetch some more information on this java-based build tool in the Ant Apache web site.

==== Using the HBuild class ====

(HBuild is the Haskell mini-distutils)

CDBS can take care of -hugs and -ghc packages: invoke 'Setup.lhs' properly for clean and install part.

To use this class, add this line to your 'debian/rules' :

<pre><nowiki>
include /usr/share/cdbs/1/class/hbuild.mk
</nowiki></pre>

You should be able to fetch some more information on Haskell distutils in this thread.

=== Chapter 5. Hall of examples ===

==== GNOME + autotools + simple patchsys example ====

(example from the 'gnome-panel' package)

'debian/control.in':

<pre><nowiki>
Source: gnome-panel
Section: gnome
Priority: optional
Maintainer: Marc Dequènes (Duck) <Duck@DuckCorp.org>
Uploaders: Sebastien Bacher <seb128@debian.org>, Arnaud Patard \
<arnaud.patard@rtp-net.org>, @GNOME_TEAM@
Standards-Version: 3.6.1.1
Build-Depends: @cdbs@, liborbit2-dev (>= 2.10.2-1.1), intltool, gnome-pkg-tools, \
libglade2-dev (>= 1:2.4.0), libwnck-dev (>= 2.8.1-3), scrollkeeper \
(>= 0.3.14-9.1), libgnome-desktop-dev (>= 2.8.3-2), libpng3-dev, sharutils, \
libbonobo2-dev (>= 2.8.0-3), libxmu-dev, autotools-dev, libedata-cal-dev \
(>= 1.0.2-3)

Package: gnome-panel
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, gnome-panel-data \
(= ${Source-Version}), gnome-desktop-data (>= 2.8.1-2), gnome-session \
(>= 2.8.1-4), gnome-control-center (>= 1:2.8.1-3)
Conflicts: gnome-panel2, quick-lounge-applet (<= 0.98-1), system-tray-applet, \
metacity (<= 2.6.0), menu (<< 2.1.9-1)
Recommends: gnome-applets (>= 2.8.2-1)
Suggests: menu (>= 2.1.9-1), yelp, gnome2-user-guide, gnome-terminal | \
x-terminal-emulator, gnome-system-tools
Description: launcher and docking facility for GNOME 2
This package contains toolbar-like “panels” which can be attached to
the sides of your X desktop, or left “floating”. It is designed to be
used in conjunction with the Gnome Desktop Environment. Many features
are provided for use with the panels – including an application menu,
clock, mail checker, network monitor, quick launch icons and the like.

Package: libpanel-applet2-0
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Replaces: gnome-panel (<< 2.6.0-2)
Description: library for GNOME 2 panel applets
This library is used by GNOME 2 panel applets.

Package: libpanel-applet2-dbg
Section: libdevel
Architecture: any
Depends: libpanel-applet2-0 (= ${Source-Version})
Description: library for GNOME 2 panel applets - library with debugging symbols
This library is used by GNOME 2 panel applets.
.
This package contains unstripped shared libraries. It is provided primarily
to provide a backtrace with names in a debugger, this makes it somewhat
easier to interpret core dumps. The libraries are installed in
/usr/lib/debug and can be used by placing that directory in
LD_LIBRARY_PATH.
Most people will not need this package.

Package: libpanel-applet2-dev
Section: libdevel
Architecture: any
Depends: libpanel-applet2-0 (= ${Source-Version}), libgnomeui-dev (>= 2.7.1-1)
Replaces: gnome-panel (<< 2.6.0-2), gnome-panel-data (<< 2.6.0)
Description: library for GNOME 2 panel applets - development files
This packages provides the include files and static library for the GNOME 2
panel applet library functions.

Package: libpanel-applet2-doc
Section: doc
Architecture: all
Suggests: doc-base
Replaces: libpanel-applet2-dev (<= 2.0.11-1)
Description: library for GNOME 2 panel applets - documentation files
This packages provides the documentation files for the GNOME 2 panel applet
library functions.

Package: gnome-panel-data
Section: gnome
Architecture: all
Depends: gnome-panel (= ${Source-Version}), scrollkeeper (>= 0.3.14-9.1), \
${misc:Depends}
Conflicts: gnome-panel-data2, gnome-core (<< 1.5)
Replaces: gnome-desktop-data (<= 2.2.2-1), gnome-panel (<< 2.6.0-2)
Description: common files for GNOME 2 panel
This package includes some files that are needed by the GNOME 2 panel
(Pixmaps, .desktop files and internationalization files).
</nowiki></pre>

'debian/rules':

<pre><nowiki>
#!/usr/bin/make -f

# Gnome Team
include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk

include /usr/share/cdbs/1/rules/debhelper.mk
# Including this file gets us a simple patch system.  You can just
# drop patches in debian/patches, and they will be automatically
# applied and unapplied.
include /usr/share/cdbs/1/rules/simple-patchsys.mk
# Including this gives us a number of rules typical to a GNOME
# program, including setting GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1.
# Note that this class inherits from autotools.mk and docbookxml.mk,
# so you don't need to include those too.
include /usr/share/cdbs/1/class/gnome.mk

DEB_CONFIGURE_SCRIPT_ENV := LDFLAGS="-Wl,-z,defs -Wl,-O1"
DEB_CONFIGURE_EXTRA_FLAGS := --enable-eds

# debug lib
DEB_DH_STRIP_ARGS := --dbg-package=libpanel-applet-2

# tight versioning
DEB_NOREVISION_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | \
cut -f 2 -d ' ' | cut -f 1 -d '-')
DEB_DH_MAKESHLIBS_ARGS_libpanel-applet2-0 := -V"libpanel-applet2-0 \
(>= $(DEB_NOREVISION_VERSION))"
DEB_SHLIBDEPS_LIBRARY_gnome-panel:= libpanel-applet2-0
DEB_SHLIBDEPS_INCLUDE_gnome-panel := debian/libpanel-applet2-0/usr/lib/


binary-install/gnome-panel::
chmod a+x debian/gnome-panel/usr/lib/gnome-panel/*

binary-install/gnome-panel-data::
chmod a+x debian/gnome-panel-data/etc/menu-methods/gnome-panel-data
find debian/gnome-panel-data/usr/share -type f -exec chmod -R a-x {} \;

binary-install/libpanel-applet2-doc::
find debian/libpanel-applet2-doc/usr/share/doc/libpanel-applet2-doc/ \
-name ".arch-ids" -depth -exec rm -rf {} \;

clean::
# GNOME Team 'uploaders.mk' should not override this behavior
#   here is a workarround :
sed -i "s/@cdbs@/$(CDBS_BUILD_DEPENDS)/g" debian/control
# cleanup not done by buildsys
-find . -name "Makefile" -exec rm -f {} \;
</nowiki></pre>


==== Python example ====

(example from 'python-dice', an unofficial DC package)

'debian/control.in':

<pre><nowiki>
Source: python-dice
Section: python
Priority: optional
Maintainer: Marc Dequènes (Duck) <Duck@DuckCorp.org>
Standards-Version: 3.6.1.1
Build-Depends: @cdbs@, python2.3-dev, python2.4-dev, swig, libdice2-dev \
(>= 0.6.2.fixed.1)

Package: python-dice
Architecture: all
Depends: python2.3-dice
Description: python bindings for dice rolling and simulation library
PyDice is a python module for dice rolling and simulation (using fuzzy
logic).
.
It provides a Python API to the libdice2 library.
.
This is a dummy package automatically selecting the current Debian
python version.

Package: python2.3-dice
Architecture: any
Depends: ${python:Depends}
Description: python bindings for dice rolling and simulation library
PyDice is a python module for dice rolling and simulation (using fuzzy
logic).
.
It provides a Python API to the libdice2 library.

Package: python2.4-dice
Architecture: any
Depends: ${python:Depends}
Description: python 2.4 bindings for dice rolling and simulation library
PyDice is a python module for dice rolling and simulation (using fuzzy
logic).
.
It provides a Python 2.4 API to the libdice2 library.
</nowiki></pre>

'debian/rules':

<pre><nowiki>
#!/usr/bin/make -f


include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/python-distutils.mk
</nowiki></pre>


==== Makefile + Dpatch example ====

(example from the 'apg' package)

'debian/control.in':

<pre><nowiki>
Source: apg
Section: admin
Priority: optional
Maintainer: Marc Haber <mh+debian-packages@zugschlus.de>
Build-Depends: @cdbs@
Standards-Version: 3.6.1

Package: apg
Architecture: any
Depends: ${shlibs:Depends}
Description: Automated Password Generator - Standalone version
APG (Automated Password Generator) is the tool set for random
password generation. It generates some random words of required type
and prints them to standard output. This binary package contains only
the standalone version of apg.
Advantages:
* Built-in ANSI X9.17 RNG (Random Number Generator)(CAST/SHA1)
* Built-in password quality checking system (now it has support for Bloom
filter for faster access)
* Two Password Generation Algorithms:
1. Pronounceable Password Generation Algorithm (according to NIST
FIPS 181)
2. Random Character Password Generation Algorithm with 35
configurable modes of operation
* Configurable password length parameters
* Configurable amount of generated passwords
* Ability to initialize RNG with user string
* Support for /dev/random
* Ability to crypt() generated passwords and print them as additional output.
* Special parameters to use APG in script
* Ability to log password generation requests for network version
* Ability to control APG service access using tcpd
* Ability to use password generation service from any type of box (Mac,
WinXX, etc.) that connected to network
* Ability to enforce remote users to use only allowed type of password
generation
The client/server version of apg has been deliberately omitted.
.
Upstream URL: http://www.adel.nursat.kz/apg/download.shtml
</nowiki></pre>

'debian/rules':

<pre><nowiki>
#!/usr/bin/make -f


DEB_MAKE_CLEAN_TARGET    := clean
DEB_MAKE_BUILD_TARGET    := standalone
DEB_MAKE_INSTALL_TARGET  := install INSTALL_PREFIX=$(CURDIR)/debian/apg/usr

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/rules/dpatch.mk
include /usr/share/cdbs/1/class/makefile.mk

cleanbuilddir/apg::
rm -f build-stamp configure-stamp php.tar.gz

install/apg::
mv $(CURDIR)/debian/apg/usr/bin/apg \
$(CURDIR)/debian/apg/usr/lib/apg/apg
tar --create --gzip --file php.tar.gz --directory \
$(CURDIR)/php/apgonline/ .
install -D --mode=0644 php.tar.gz \
$(CURDIR)/debian/apg/usr/share/doc/apg/php.tar.gz
rm php.tar.gz
install -D --mode=0755 $(CURDIR)/debian/apg.wrapper \
$(CURDIR)/debian/apg/usr/bin/apg
install -D --mode=0644 $(CURDIR)/debian/apg.conf \
$(CURDIR)/debian/apg/etc/apg.conf
</nowiki></pre>

==== Perl example ====

(example from the 'libmidi-perl' package)

'debian/control':

<pre><nowiki>
Source: libmidi-perl
Section: interpreters
Priority: optional
Build-Depends: cdbs (>= 0.4.4), debhelper (>= 4.1.0), perl (>= 5.8.0-7)
Maintainer: Mario Lang <mlang@debian.org>
Standards-Version: 3.5.10

Package: libmidi-perl
Architecture: all
Depends: ${perl:Depends}
Description: read, compose, modify, and write MIDI files in Perl
This suite of Perl modules provides routines for reading, composing,
modifying, and writing MIDI files.
</nowiki></pre>

'debian/rules':

<pre><nowiki>
#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/perlmodule.mk
</nowiki></pre>


=== Chapter 6. Useful tools ===

==== cdbs-edit-patch (provided with CDBS) ====

This script is intended to help lazy people edit or create patches easily.

Invoke this script with the name of the patch as argument, and you will enter a copy of your work directory in a subshell where you can edit sources.
When your work is done and you are satisfied with your changes, just exit the subshell and you will get back to normal world with 'debian/patches/<patch_name>.patch' created or modified accordingly.
The script takes care to apply previous patches (ordered patches needed !), current patch if already existing (in case you want to update it), then generate an incremental diff to only get desired modifications.
If you want to cancel the patch creation / modification, you only need to exit the subshell with a non-zero value and the diff will not be generated (only cleanups will be done).

=== Chapter 7. Conclusion ===

CDBS solves most common problems and is very pleasant to use. More and more DD are using it, not because they are obliged to, but because they tasted and found it could improve their packages and avoid loosing time on designing silly and complicated rules.

CDBS is not perfect, the BTS entry is not clear, but fixing a single bug most of the time fix a problem for plenty of other packages. CDBS is not yet capable of handling very complicated situations (like packages where multiple C/C++ builds with different options and/or patches are required), but this only affects a very small number of packages. These limitations would be solved in CDBS2, which is work in progress (please contact Jeff Bailey <jbailey@raspberryginger.com> if you want to help).

Using CDBS more widely would improve Debian's overall quality.
Don't hesitate trying it, talking to your friends about it, and contributing.

Have a Lot of FUN with CDBS !!! :-)

'''Thanks'''

Thanks to Jeff for his patience and for replying my so many questions.

Special thanks to GuiHome for his help to review this documentation.

This document is a DocBook application, checked using xmllint (from libxml2), produced using xsltproc (from libxslt), using the N. Walsh and DB2LaTeX XLST stylesheets, and converted with LaTeX tools (latex, mkindex, pdflatex & dvips) / pstotext (with GS).