openSUSE:Build Service Debian builds
tagline: From openSUSE
Debian Builds
This page will provide info on packaging for the Debian-based Linux distributions supported by the openSUSE Build Service, currently Debian itself and Ubuntu.
Debian packages are divided in 2 categories: binary and source. The binary packages have .deb extension and they contain the compiled version of the application you want to distribute. The source packages are not a single file (like .src.rpm mechanism); instead, they are composed of three files:
- The pristine tarball
- A diff file
- A .dsc file
The Build Service will not create a source repository for .deb-based distributions, but only the .deb will be created
Hence, it is important to keep in mind that a "standard" Debian repository is composed of at least two directories:
(your repository root) | +-binary +-source
while the Build Service will create only the binary directory with the name of distribution, e.g. http://download.opensuse.org/repositories/home:/yourself/Debian_Etch/ corresponding to the binary directory instead of the repository root (which would be http://download.opensuse.org/repositories/home:/yourself/ ).
Also, keep in mind that the three parts for creating a source package are not needed in order to create a .deb package. Instead, they are necessary when you create a source repository and allow for automatically compiling and packaging on the user's machine via apt-get.
The Build Service will not create a source repository, so you simply do not need to know how they are constructed and used.
The Build Service also uses some magic. Some extra information can be given in the .dsc file in the form of "debtransform" tags. Those are documented in this mail: http://lists.opensuse.org/opensuse-buildservice/2007-03/msg00067.html and the source code can be found at http://gitorious.org/opensuse/build/blobs/master/debtransform . By looking at it, you can see that it accepts three tags:
- DEBTRANSFORM-TAR
- DEBTRANSFORM-FILES-TAR
- DEBTRANSFORM-SERIES
These can be used to specify a .tar.gz file as source, that can be shared between RPM and debian based builds, and can also be used to reuse the RPM patches in the debian builds. You can use multiple tar.gz files for the DEBTRANSFORM-FILES-TAR like this:
Debtransform-Files-Tar: debian.tar.gz debian-control-xUbuntu_6.06.tar.gz
Required rpms on the host system to build .deb packages
The following packages are needed on openSUSE based distributions to build .deb packages locally with osc (osc build ....):
- deb (for 'dpkg')
- binutils (for 'ar')
Install them with:
Minimum set of files required to create .deb
In order to create a .deb package successfully, you have to create at least these files:
- packageName.dsc
- debian.changelog
- debian.control
- debian.rules
And of course a tarball (tar.gz) that contains the package source code to compile.
packageName.dsc
A minimal template for this file is:
Format: 1.0 Source: packageName Version: 5.6-3 Binary: packageName Maintainer: FirstName LastName <email@hostname.org> Architecture: any Build-Depends: debhelper (>= 4.1.16), nameOfPackageNeededToBuildIt Files: d57283ebb8157ae919762c58419353c8 133282 packageName_5.6.orig.tar.gz 2fecf324a32123b08cefc0f047bca5ee 63176 packageName_5.6-1.diff.tar.gz
In the above template are listed only the mandatory fields, but there are many optional fields. You can find all information about these fields at http://www.debian.org/doc/debian-policy/ch-controlfields.html
I explain here a summary for let you to understand what they means:
- Format : is the format version of the .deb package. Write 1.0
- Source : is the name of source package without .tar.gz
- Version : is composed by the version of the source and the revision of the package; in the template 5.6 is the version of the source code, while 3 (after '-') is the revision of the debian package. Every time you change one of the files necessary to create a .deb you should increment it
- Binary : is the name of binary package as seen by the apt manager (e.g: for install it you specify apt-get install theNameYouWriteInBinaryField )
- Maintainer : is the name of source maintainer (not your name, or packager name)
- Architecture : the list of architecture you want to compile it
- Build-Depends : the library necessary for compile it. You Must specify 'debhelper (>= 4.1.16)' because it contains all helper script used by the system for compile
- Files: in theory you must specify the MD5SUM and dimension in byte of the .orig.tar.gz and .diff.tar.gz, but in practice just put some values, is not important if they are not correct... the important is that there are two lines with three field as showed in the template. (e.g. you can cat and paste the two lines in the template and substitute packageName with the name of the .deb you want to create and it's ok... Build Service will do the rest)
debian.changelog
The Debian mechanism for creating a .deb is to put inside the source tree a directory called 'debian' with a lot of files necessary to automate the compiling and packaging process.
You don't need to do it by yourself, the Build Service will create the directory for you and it will put all files called debian.fileName
This is valid for all .deb-based distributions!! Hence, also for Ubuntu repository you have to create a file called debian.changelog (and not ubuntu.changelog).
This is the minimal template:
packageName (5.6-3) stable; urgency=low * Initial Release -- YourName <youremail@hostname.de> Mon, 25 Dec 2007 10:50:38 +0100
You could think that it's just a changelog... but the syntax is so constrained that a little error (a whitespace missing) that all process of creating package fails !! :-( So, pay attention to the syntax specified at http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
If you add a debian.changelog, OBS checks, if the version number of the changelog matches the dsc file. If not, it adds a fake entry containing the version number of the dsc file. This ensures, that the version of source and binary package stays in sync.
debian.control
This file are used to describe the package and the dependencies, this if a minimal template:
Source: packageName
Section: sectionName
Priority: optional
Maintainer: yourName <yourEmail@hostname.de>
Build-Depends: debhelper (>= 4.1.16), nameOfPackageNeededToBuildIt
Package: nameOfPackage
Architecture: any
Depends: ${shlibs:Depends}
Description: This first line is a brief description
Then, here there is the long description of the package...
also here the syntax is very painful (look at the documentation of Debian Policy
to avoid errors http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f- Description)
Here there are some informations redundant that you can copy from .dsc file: 'Build- Depends', 'Package' is the same of 'Binary', 'Architecture', 'Maintainer' typically is the same of last list of debian.changelog
debian.rules
This is a Makefile-style file that contains all the rules for extracting, compiling, installing and packaging the source. You can change what you'd like inside this file, but it's simpler to change just a few lines to get it to compile. The rest of the file can be left untouched.
#!/usr/bin/make -f # Sample debian/rules that uses debhelper. # GNU copyright 1997 to 1999 by Joey Hess. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 # This is the debhelper compatibility version to use. export DH_COMPAT=4 CFLAGS = -g ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O2 endif build: build-stamp build-stamp: dh_testdir # Add here commands to compile the package. ./configure make all # --- end custom part for compiling touch build-stamp clean: dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. make clean || true # --- end custom part for cleaning up dh_clean install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package # The DESTDIR Has To Be Exactly /usr/src/packages/BUILD/debian/<nameOfPackage> make install DESTDIR=/usr/src/packages/BUILD/debian/ace # --- end custom part for installing # Build architecture-independent files here. binary-indep: build install # We have nothing to do by default. # Build architecture-dependent files here. binary-arch: build install dh_testdir dh_testroot # dh_installdebconf dh_installdocs dh_installexamples dh_installmenu # dh_installlogrotate # dh_installemacsen # dh_installpam # dh_installmime # dh_installinit dh_installcron dh_installman dh_installinfo # dh_undocumented dh_installchangelogs dh_link dh_strip dh_compress dh_fixperms # dh_makeshlibs dh_installdeb # dh_perl dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install
Adding a patch
In order to apply a patch to your sources you need to add a debian.series file containing the name of the patch(es) and parameters to the patch utility, e.g.
avoid_sysarg.patch -p0
An Alternative method of creating a Debian package
The above implies that to create a Debian package, you must create files at least 5 files:
- packageName.dsc
- debian.changelog
- debian.control
- debian.rules
- tarball (tar.gz)
However there is an alternative way: Create (or reuse) a standard Debian source package using native Debian or Ubuntu tools! To review, a standard Debian source package consists of three files:
- The pristine tarball
- Either a diff file or a debian tarball
- A .dsc file
Such a source package can be created on Debian systems using scripts such as "dpkg-buildpackage -S" or "dpkg-source -b" as described in the Debian documentation.
Such a triple of files can be uploaded to the buildservice as source files and the build service can use these files to build a package. The information in the various debian.xxx files is still there, but it is concealed in the diff file or the debian tarball.
Often Debian source packages need to be created for reasons having nothing to do with the buildservice. If such a source package exists, there is no reason not to use it.
Alternatively, the "service" feature of "add file" can be used to specify the files to be used by URI. That way, the build service will download the three files from an existing Debian or Ubuntu source repository!
If one looks at source packages displayed by http://packages.ubuntu.com/ (Ubuntu Packages Search) one will find at the bottom of a page displaying a source package, the URLs of the three files that are the source package. These URLs can be copied to the clipboard using your browser's "copy link" function. The URLs can then be used by the buildservice's "add file" pages. (In the "Upload from remote URL" field of this page.) In this way you can cause the buildservice to rebuild one of the packages from say, the Ubuntu "Universe" repository, without ever having any form of the source on your system.
Providing different configurations for different distro versions
In order to use different configurations for multiple Debian or Ubuntu versions, you have to use the alternative method of creating the Debian package. The .dsc files should be named in a similar manner to the scheme for alternative .spec files for RPM based distros, i.e. projectName-repository.dsc , . Different .dsc files can refer to different source tarballs if necessary.
Example:
- wonderproj-xUbuntu_10.10.dsc
- wonderproj-new_0.0.1-1.debian.tar.gz
- wonderproj-new_0.0.1.orig.tar.bz2
In this case, wonderproj-xUbuntu_10.10.dsc would contain references like this:
Format: 3.0 (quilt) Source: wonderproj-new Binary: wonderproj-new Architecture: any Version: 0.0.1-1 Maintainer: I.M.Coder <im@wonder-code.org> Standards-Version: 0.0.1 Build-Depends: cdbs, cmake, debhelper, pkg-kde-tools, kdelibs5-dev Checksums-Sha1: 0ba9af478421ce1b0ca652b0d035a49ed4f5513f 2893892 wonderproj-new_0.0.1.orig.tar.bz2 f0d12c000ac09c48439408e2978eea56f152ae1c 20710 wonderproj-new_0.0.1-1.debian.tar.gz Checksums-Sha256: 0afd23eecf11a8d387019a007064c6554dad3adaf640c28a39a12143ac8ccc19 2893892 wonderproj-new_0.0.1.orig.tar.bz2 f10e4a9ff5b629b2b73e8b6ca97f4d47b7ac4e53c33930db1e5fefc317f2c123 20710 wonderproj-new_0.0.1-1.debian.tar.gz Files: 437a8d1df895203af8b08e64717a6e30 2893892 wonderproj-new_0.0.1.orig.tar.bz2 0323ebdd4a1983de61a5e4f326194426 20710 wonderproj-new_0.0.1-1.debian.tar.gz
Handling build dependency differences
If you need to supply extra build dependencies for some distro versions, they can be supplied in the Build-Depends line in the .dsc files.
If any build dependencies contained in debian/control (in the .debian.tar.gz file) are not applicable to some distro versions, remove them from debian/control and, for distro versions which still require them, add them to the appropriate .dsc files instead.
You may need to remove version number specifications from build dependencies in the debian/control file, if these are wrong for some distro versions.
If the debian/control file has been modified, make it available as follows:
- Recreate the .debian.tar.gz file to include the modified debian/control file
- Modify the .dsc files to contain the new checksums and file size of the .debian.tar.gz file. The new checksums can be obtained using the commands md5sum, sha1sum and sha256sum.
Configuring sources.list
After the creation of .deb packages, you want to add the repository to the sources.list file (probably in /etc/apt/) in order to use apt-get to install your package(s).
Here is an example entry.
deb http://download.opensuse.org/repositories/home:/robermann79:/codesounding/Ubuntu_8.10 ./
The problem is that apt-get does not handle HTTP redirections (302) for mirrors, and apt-get considers that an error.
It's not a bug in apt-get. It's a decision made by the apt developers; they consider it a very unsafe choice to use 302 redirection for package repository (Why? They haven't yet told us. They just said that it's unsafe)
But you can solve this problem in two ways:
- if you have a server, mirror the repository there and point users to that
- search on http://old-en.opensuse.org/Mirrors_Development_Build for a server that mirrors your repository and point users to that (hoping that the mirror is permanent)
The quick way is to get a mirror list from the repository itself:
- Browse to the mirror list:
http://download.opensuse.org/repositories/<project>://<package>/<repository>/Packages?mirrorlist
So, for example:
http://download.opensuse.org/repositories/home://robermann79://codesounding/Ubuntu_8.10/Packages?mirrorlist
- pick one of the mirrors listed, for example:
http://widehat.opensuse.org/repositories/home:/robermann79:/codesounding/Ubuntu_8.10/Packages
then remove the last "/Packages" path and add the URL to your /etc/apt/sources.list, as follows:
deb http://widehat.opensuse.org/repositories/home:/robermann79:/codesounding/Ubuntu_8.10 ./
Now apt-get commands work as expected.
Adding the apt-key to the system
For modern Debian GNU/Linux based distributions, you will also need to add the project's repository key to the list of keys accepted by apt.
- you can take the one from api.opensuse.org, eg: https://api.opensuse.org/source/home:herzi/_pubkey (replace "home:herzi" with your project, you'll need your OBS credentials)
- or take one from a repomd archive, eg: http://download.opensuse.org/repositories/home:/herzi/xUbuntu_11.04/Release.key (replace "home:/herzi" with your project and "xUbuntu_11.04" with a repository of the project, this one is of public access)
Then you can add the downloaded key:
sudo apt-key add <downloaded-file>
Examples
You can see examples in my home project directory: https://build.opensuse.org/project/show?project=home%3AEmmeG
Common pitfalls
Note on packageName
RPM packages names do not have a strict syntax like the debian ones. So watch out before uploading your archives !
- Package names (both source and binary, see Package, Section 5.6.7) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character.
More informations at http://www.debian.org/doc/debian-policy/ch-controlfields.html
Note on tar.bz2
Debian 4.0 and xUbuntu 8.04 and earlier allowed for package.tar.bz2 files to be used. These could be shared between deb and rpm builds. Debian 5.0 and xUbuntu 8.10 only allow for package.tar.gz files as per Debian policy. To share sources between rpm and deb builds for all platforms in OBS, it's recommended to use package.tar.gz files.
When the upstream tar file is in tar.bz2 format (or any other for that matter), the recompress service will be useful to recompress it into the standard tar.gz format.
A useful example:
<services>
<service name="download_url">
<param name="host">master.dl.sourceforge.net</param>
<param name="protocol">http</param>
<param name="path">/project/someproject/somefolder/someproject.data.tar</param>
</service>
<service name="recompress">
<param name="file">_service:download_url:someproject.data.tar</param>
<param name="compression">gz</param>
</service>
</services>
Note the _service:download_url: prefix, it's required, and it won't work without it if you're recompressing a file downloaded by a service.
In the Web UI, this means you have to edit the service's parameters accordingly after creating the entry (it won't be initially correct)
Note on "postinst" (post installation) scripts
If you need to run some script on post installation, you could:
- upload a file named debian.postinst (see the prefix "debian"), as for debian.rules
- put your package.postinst file (where "package" is your package name) inside the debian.tar.gz
See as example the package https://build.opensuse.org/package/show?package=openvas-scanner&project=security%3AOpenVAS%3ASTABLE%3Av4
Patch format
Debian 4.0 and xUbuntu < 8.x require the to be patched file and the new one to have the same name for -p0 patches (Bug #492297 ).
xUbuntu 6.06 additionally doesn't allow content after the @@..@@ line. E.g.
@@ -37,7 +37,7 @@ openvas-libraries.tmpl: openvas-librarie
will fail while
@@ -37,7 +37,7 @@
will work just fine. Simply removing the content after the second @@ should solve this.
Linking -dev packages to their main one
Ubuntu 6.06 doesn't understand "(= ${binary:Version})" in the .control file. There "(= ${Source-Version})" has to be used.
Debian documentation
Some useful links to Debian documentation:
