- Introduction to Package Management
- Debian Packages
- Package Management in Ubuntu
- Making Your Own Packages
This chapter is from the book
This chapter is from the book
This chapter is from the book
Making Your Own Packages
The power of a package management system is that you can track dependencies and conflicts, do automatic upgrades, and keep track of every file on the system and which piece of software it belongs to. Installing through packages is much easier than if one simply downloads and builds from scratch, but the package management system truly shines when it comes time to uninstall or upgrade. If you’ve installed from source, files may be in any number of places on your file system. If you’ve installed from a package, removing your package will be as simple as apt-get remove.
As a result, many responsible system administrators find it very convenient to ensure that all software on their systems is installed from packages. That sounds great, but sometimes a piece of software you want—or a version of a piece of software that you want—isn’t packaged or isn’t built for the version of Ubuntu that you are running. The result is that you’ll need to build, in one way or another, your own packages. The rest of this chapter gives a brief overview of this process and provides a starting spot for the system administrator who wants to move beyond simply consuming packages and become a producer.
Rebuilding Packages
As I hinted earlier in this chapter, many users want to rebuild existing packages as part of “backporting” a version of a piece of software available in one version of Ubuntu—or Debian—to a current one. Sometimes, if an ABI has changed, a piece of software won’t work on a version of Ubuntu simply because it was compiled against a set of libraries that are no longer present. This is the easiest possible case to fix because adjusting for it is simply a matter of downloading the source and rebuilding it against the new version of the libraries. This section will cover doing exactly this.
Doing so will first require a source package. The source package, as you may remember from earlier in this chapter, consists of a DSC file and at least one other file. These can be downloaded as normal files from http://packages.ubuntu.com and unpacked with dpkg-source -x filename.dsc, or they can be installed automatically by using the apt-get source package command.
If one wanted to download and compile a package from a particular distribution—as is often the case—one could specify this explicitly with the -t option, which, behind the scenes, sets the default PIN for the distribution at a very high priority (990 in fact) by running (for example)
$ apt-get -t jaunty source --compile most
This would download and unpack the version of most source packages from Jaunty—assuming, of course, that the necessary deb-src line was included in /etc/apt/sources.list. The unpacked source code will be in a subdirectory of the current directory made up of the package name and version. In this case, the directory would be called most-5.0.0a since 5.0.0.a is the version of most that I’ve downloaded. By adding a --compile flag to the apt-get invocation above, the binary packages will also be built automatically—even if the program is in an interpreted language and there is no actual compiling taking place. If one does not use the compile flag, it can be invoked afterward in several ways. One of the simplest is by changing into the directory and then running dpkg-buildpackage like this:
$ cd most-5.0.0a $ dpkg-buildpackage -us -uc -rfakeroot
This command will create an unsigned package (the -us and the -uc refer to unsigned source and unsigned changelog files) without needing root privileges (fakeroot is a program that allows packages to be built without root). Of course, the package may also require build dependencies that are not installed by running a command in the following form:
# apt-get -t jaunty build-dep most
The build-dep subcommand to apt-get automates the process of installing all software necessary to build a given package. Running it is a frequent first step in rebuilding any package for the first time when that package is from an installed repository.
When the software in question is successfully rebuilt, the directory will contain a set of binary packages for this source package that end with .deb in the directory where it is run. In this case, the single binary package created was called most_5.0.0a-1_i386.deb. The -1 following the version number of the software refers to the version of the package and could be incremented each time we made a new version of the package. The i386 in this case simply refers to the architecture for which the binary package was built. In this case, I built it on an Intel machine. For many users, this will say amd64, which is an increasingly popular architecture. For most interpreted programs that will run on any architectures, this will say all.
New Upstream Versions
New upstream versions of packages are slightly more complicated than simply rebuilding an existing package with no modifications. Installing the package devscripts will provide the user with a program called uupdate which helps with this process. To use uupdate, a user first needs to download the source package with a command like apt-get source most. I don’t want it to compile at the moment so I will leave off the compile option. Additionally, I will download the new upstream version tarball. There is no reason to unpack it at this point and, optionally, rename it into name-version.tar.gz format. Changing into the directory of the old package’s source and running uupdate with the new upstream tarball as the argument will usually do the trick:
$ cd most-5.0.0a $ uupdate ../most-5.0.1.tar.gz
Usually, uupdate will then deduce the version number from the upstream tarball and apply all the changes made to the old version to the new upstream source. If uupdate can’t decode the version number, the new version number can be specified as a second argument to the command.
The output from uupdate should explain the process that it follows and will end with a description of the location of the new modified source. In this case, changing to ../most-5.0.1 will put me in the new “updated” package directory. It’s a good idea to look around first to make sure that things worked well. Especially it is worth checking the debian/ subdirectory and paying attention to both the control file and the changelog file in that directory, the latter of which will have been updated automatically but will probably need a little bit of tweaking. The stanza at the top will include information on the new release and can be updated or tweaked to reflect changes that you made to the file. Once you are satisfied, you can build the package with dpkg-buildpackage in the way described in the previous section.
Building Packages from Scratch
Building packages from scratch is much more complicated and involves getting to know quite a bit about the internals of Debian packages. As a result, it is outside the scope of this chapter. As a hint, new packages can be most easily created using the package dh-make, which installs the program dh_make, which is invoked from inside the unpacked source tarball from the upstream developer. For many simple packages, dh_make does most of the hard work of creating workable packages.
Much more information on creating packages for Ubuntu can be found in the Ubuntu packaging guide, which goes in depth into the process of creating packages from scratch: https://wiki.ubuntu.com/PackagingGuide.
It is worth noting one important caveat to the Ubuntu documentation, which is that the packaging guide is focused on creating packages that are designed to be uploaded to Ubuntu. If you are creating packages that will be installed only on your own machine, the potential for harm is much less, and many of the guidelines in the packaging guide can be treated as just that—especially in the first version of a package. The difference is between workable packages and policy-compliant packages.
If you are going to proceed and create packages to be shared with others or perhaps even uploaded into the Ubuntu repositories eventually, it is a very good idea to follow the instructions in the packaging guidelines carefully and to use programs like lintian, which will check your packages for many common errors—useful steps in any situation. If you just want things to work, a brief trip through the guide and use of dh_make will probably put you in good enough shape to get by.
Hosting Your Own Packages
A final step in the creation of your packages will be hosting them in a place where others can get them in the simple “add a line to your source.list file” sort of manner to which I have referred throughout this chapter. There are several different ways to do this. The easiest one and the one most commonly practiced in the Ubuntu world is to use Launchpad—the infrastructure built by Canonical and used extensively in Ubuntu’s own development—to host what’s called a Personal Package Archives.
With a PPA, a developer can simply upload a source package to Launchpad and the package will then be built on a variety of architectures and posted into a PPA. PPAs work exactly the same way that developing for Ubuntu does, so using them is a great preview of what you will experience if you decide to eventually upload your software in Ubuntu and get involved on the development side of things. Earlier, when I showed how to add Bazaar packages to the list of packages, I entered the list of the Bazaar PPAs. More information on PPAs is available at the following URLs: https://help.launchpad.net/Packaging/PPA and https://launchpad.net/ubuntu/+ppas.
Alternatively, you can host your own repository on your own server with any of several different tools. Although the classic tool for running these is a package called apt-ftparchive, the newer project reprepro is probably a better fit. Installing the package with that name and looking in the documentation is a good way to get started.