XiVO is developped from a GIT repository and the corresponding Debian GNU/Linux packages are maintained in a SVN repository. An internal tool is used to build Debian GNU/Linux source packages by interpreting their content according to a set of conventions. A shell script was created to document and re-implemnt these conventions. The latest XiVO skaro release for squeeze is used as an example.
Source GIT structure
The GIT repository can be extracted as follows:
git clone git://git.xivo.fr/xivo-skaro.git
It contains a directory for each source package found in the skaro repository. The names of the directories are mapped to the package names as follows:
agid -> pf-xivo-agid app_nv_faxdetect -> pf-asterisk-app-nv-faxdetect asterisk -> asterisk base-config -> pf-xivo-base-config bntools -> bntools chan_sccp -> asterisk-chan-sccp confgen -> pf-xivo-confgen ctiservers -> pf-xivo-cti-server dahdi-linux -> dahdi-linux dahdi-tools -> dahdi-tools extra -> pf-xivo-extra fetchfw -> pf-xivo-fetchfw freeswitch -> freeswitch lib-javascript -> pf-xivo-lib-js lib-python -> pf-xivo-lib-python monitoring -> pf-xivo-monitoring provisioning -> pf-xivo-provisioning queues-logger -> pf-xivo-queues-logger res_watchdog -> pf-asterisk-res-watchdog sysconfd -> pf-xivo-sysconfd utils -> pf-xivo-utils web-interface -> pf-xivo-web-interface xivo-sounds -> pf-xivo-sounds
The mapping is found in the */Makefile.pkg file, in the DEB_PKG variable, such as
DEB_PKG="pf-xivo-monitoring"
There are two sets of directories : the software imported from a third party (asterisk, for instance) and the software developped natively.
The source tarbal of a native package is created from a tar of the directory, not including the directory name. For instance, the pf-xivo-cti-server tarbal contains:
-rw-r--r-- root/root 305 ./Makefile.pkg -rw-r--r-- root/root 6922 ./xivo_daemon.conf -rw-r--r-- root/root 35068 ./LICENSE drwxr-xr-x root/root 0 ./xivo_ctiservers/ -rw-r--r-- root/root 8011 ./xivo_ctiservers/cti_trunklist.py -rw-r--r-- root/root 13509 ./xivo_ctiservers/xivo_phones.py -rw-r--r-- root/root 3199 ./xivo_ctiservers/cti_presence.py ...
The source tarbal of a third party package is created with a tar of the patches and tarballs directories alone. The rest of the files are used during the development cycle ( such as asterisk/fetch_tarball.sh to synchronize with the asterisk upstream ) and are out of the scope of this discussion. For instance, the content of the dahdi-linux tarbal is as follows:
drwxr-xr-x root/root 0 ./patches/ -rw-r--r-- root/root 1106 ./patches/enable_oslec.diff -rw-r--r-- root/root 776 ./patches/no_firmware_download -rw-r--r-- root/root 39 ./patches/series -rw-r--r-- root/root 1147443 ./dahdi-linux_2.4.1.0+dfsg.orig.tar.gz
Note that the tarbal is moved up one directory and the tarballs directory does not show. The actual content of the corresponding GIT repository is as follows:
dahdi-linux/prepare_test_sources dahdi-linux/sources.pkg dahdi-linux/SOURCE-VERSION dahdi-linux/AUTOBUILD-IGNORE dahdi-linux/Makefile.pkg dahdi-linux/tarballs dahdi-linux/tarballs/dahdi-linux_2.4.1+dfsg.orig.tar.gz dahdi-linux/fetch_sources dahdi-linux/patches/series dahdi-linux/patches/no_firmware_download
None of the source directories contain version numbers. A convention involving a SVN version number (a SVN repository is used behind the GIT) and the content of the VERSION file (1.2 for skaro) is used to generate a version (such as the 1.2~svn10330 part of dahdi-linux_2.4.1.0+dfsg+pf.xivo.1.2~svn10330.orig.tar.gz). A simpler convention is being discussed to cope with two issues:
- the SVN version is not available to the general public
- the global version number (1.2 for skaro) is redundant and could be ignored
The directory tools is not a package. It contains files shared and duplicated in some native packages. For instance gwr.py:
app_nv_faxdetect/gwr.py -> ../tools/gwr.py res_watchdog/gwr.py -> ../tools/gwr.py tools/gwr.py
In order to ensure the inclusion of the file itself when the tarbal is created, the -h is used to store the content of the symbolic link instead of the symbolic link itself.
Some sources, such as libpri are unmodified ports of the standard package and do not require special handling.
Debian package SVN structure
The Debian GNU/Linux package are stored in an internal SVN and its publication is being discussed. The information can be retrieved from the source packages but the history is lost to the general public. The SVN tree is structured using a path named after the XiVO version and the Debian GNU/Linux version it is based on. For instance:
package=asterisk
suite=squeeze
xivo=skaro
means the packaging information will be found in
packages/branches/official/${suite}-xivo-${xivo}/${package}/trunk/debian
If the version found in debian/changelog does not reflect the source version number (for instance 2.4.1.0+dfsg+pf.xivo.1.2~svn10330 in the chapter above), a new changelog entry will be created to match it. When this sanity check is done (and assuming the source tarbal is available in the upper directory), the source package can be created with:
dpkg-buildpackage -S -uc -us
Although most packages contain a debian/control.in file, the corresponding debian/control is commited to in the SVN repository. The CDBS documentation suggests it is not a mature feature and it could probably be ignored. The newer debhelper version 7 could prefered to CDBS in the future.
Implementing the source package logic
A shell script stub has been created to implement the logic described above, together with embeded tests. When the SVN containing the Debian GNU/Linux packaging information will be available, it will create the source packages that can be fed to http://packaging-farm.dachary.org/ in order to create a XiVO skaro repository described in the series on building an independant XiVO repository.
In the second part of this entry, the script will be complete and a the XiVO skaro repository updated.