Debian package building tools

The debian. I have a script that carries out the entire process of building the packages to a local repository. It'll need to change to suit your environment, but the principles should remain the same. You'll need to enter your GPG password a few times during this process due to annoying bugs with debsign and it not supporting gpg-agent. It expects to be run from a directory that has a koha subdirectory which contains the checked out version that will be turned into packages.

The drawback to svn-buildpackage is that it doesn't have great merging support for new upstream versions. Subversion's default merge support isn't particularly great. You can use svk with the Subversion repository created by svn-buildpackage, but that has the drawback that you have to keep the orig tarball around outside of the revision control system and you can't really use svn-upgrade as easily because you want to instead use svk to do the merge.

Normally, svn-buildpackage creates a package structure like:. Check out trunk, and then put the orig tarball with the proper Debian name in the top level directory of your checkout at the same level as the package directory containing the package source. Remember to mark the orig tarball as a binary with:. Now, you can do development in your checkout of the trunk and commit changes to the upstream source, relying on svk's smerge to handle merges with new versions.

And, because of the extra nesting in the directory structure, you can then use pdebuild or debuild directly to build the package. Better yet, anyone else using this repository can just check out a working copy and have everything, including the orig tarball, needed to build the package. When a new upstream version is released, follow exactly the same procedure as given above for starting off the repository.

Branches can be used to maintain stable security updates, long-lived experimental branches, or similar forks in development. One other nice feature of svk over svn-buildpackage besides distributed development and better merging is that svk gets rid of all the. The tradeoff is that you can't just move checkouts around; svk relies on knowing where they are. For many packages, making necessary modifications in Git branches merged into the master or debian branches, or with Subversion, directly to the upstream source is sufficient.

Many packages don't require any modifications to the upstream source, and even when they are required, they're often small. The Subversion merge from svn-upgrade or the merging support in svk is often sufficient.

However, this results in a monolithic diff file and nothing else for someone else who is trying to make changes to the package for an NMU, perhaps , and means that you have to take apart that large diff file to submit patches upstream.

The utilities in the patchutils package can help with that process, but even those utilities don't help much if there are overlapping patches to the same file that are conceptually separate. This is where more complex Debian build systems come in. I've used three: quilt, dpatch, and dbs. All three have a similar basic concept, namely to not include any modifications to the upstream source in the Debian package diff and instead ship patches in a subdirectory of the debian directory and apply them at build time.

Then, each patch can be easily studied by users and by other distributions and easily sent upstream. Currently, using my Git packaging workflow , I don't use any of these systems. The Git merge facilities are more powerful.

However, this has the disadvantage of requiring others to use my Git repository rather than the resulting source package if they want to see broken-out patches. There is therefore some merit to these systems even if you love Git. They're removed during the clean target, generally by making clean depend on unpatch. One of the advantages of quilt is that it works very similar to a source control system and doesn't require a separate working tree.

You can create a new patch, add files to it, edit those files, and then run quilt refresh to save those changes to the patch. For other contact information, see the Debian contact page.

Web site source code is available. Skip Quicknav Blog Micronews Planet. Packages Introductory notes View package lists Search package directories Search the contents of packages Introductory notes All packages that are included in the official Debian distribution are free according to the Debian Free Software Guidelines.

They include: Contrib Packages in this area are freely licensed by the copyright holder but depend on other software that is not free. Non-Free Packages in this area have some onerous license condition restricting use or redistribution of the software. Search on: Package names only Descriptions Source package names. This compressed tarball contains your debian directory contents. If someone else wants to re-create your package from scratch, they can easily do so using the above three files.

This is your completed binary package. You can use dpkg to install and remove this just like any other package. This file describes all the changes made in the current package revision; it is used by the Debian FTP archive maintenance programs to install the binary and source packages.

It is partly generated from the changelog file and the. As you keep working on the package, its behavior will change and new features will be added. People downloading your package can look at this file and quickly see what has changed. Debian archive maintenance programs will also post the contents of this file to the debian-devel-changes lists. The long strings of numbers in the. Anyone downloading your files can test them with sha1sum 1 or shasum 1 and if the numbers don't match, they'll know the file is corrupt or has been tampered with.

Debian supports many ports with the autobuilder network running buildd daemons on computers of many different architectures. Although you do not need to do this yourself, you should be aware of what will happen to your packages. Let's look into roughly how they rebuild your packages for multiple architectures. For Architecture: any packages, the autobuilder system performs a rebuild. It ensures the installation of. This will do everything to make architecture dependent binary packages on another architecture.