[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ next ]


APT HOWTO
Chapter 5 - Building from source


5.1 Downloading source packages

It's common in the world of free software to study source code or even make corrections to buggy code. Building from source may also be useful if you want to enable features that are disabled in the official package, or disable some which is enabled. To do this, you would need to download the source of the program. The APT system provides an easy way to obtain source code to the many programs contained in the distribution, including all the files needed to create a .deb for the program.

Another common use of Debian sources is to adapt a more recent version of a program, from the unstable distribution, for example, for use with the stable distribution. Compiling a package against stable will generate .debs with dependencies adjusted to match the packages available in this distribution.

To accomplish this, the deb-src entry in your /etc/apt/sources.list should be pointed at unstable. It should also be enabled (uncommented). See section The /etc/apt/sources.list file, Section 3.1.

Aptitude, the Debian Package Manager is mainly targeted at binary packages. To use source packages we'll need to use apt-get instead. To download a source package, you would use the following command:

     $ apt-get source packagename

This will download three files: a .orig.tar.gz, a .dsc and a .diff.gz. In the case of debian-native packages, the last of these is not downloaded and the first usually won't have "orig" in the name.

The .dsc file is used by dpkg-source for unpacking the source package into the directory packagename-version. Within each downloaded source package there is a debian/ directory that contains the files needed for creating the .deb package.

To auto-build the package when it's been downloaded, just add -b to the command line, like this:

     $ apt-get -b source packagename

If you decide not to create the .deb at the time of the download, you can create it later by running the following command from within the directory that was created for the package after downloading:

     $ dpkg-buildpackage -rfakeroot -uc -b

Notice that to build most packages you'll need at least the following packages: devscripts, dpkg-dev, debhelper, fakeroot, take a look at Installing and reinstalling packages, Section 4.4 and install them before proceeding. Most packages will also depend on compilation tools, so it may be useful to install the build-essential package as well. Other packages may be needed, take a look at Packages needed for compiling a source package, Section 5.2 for more information.

To install the package built by the commands above one must use the package manager directly. Take a look at Installing manually downloaded or locally created debian packages, Section 4.5. A useful tool is provided by the devscripts package: debi. If you run debi from inside the source package directory it will look for the .changes file at the parent directory to discover what are the binary packages the package produces and will run dpkg to install all of them. While this is not very useful if your source package produces conflicting packages, it might be in most circunstances. Of course you need root powers in order to perform this.

There's a difference between apt-get's source method and its other methods. The source method can be used by normal users, without needing special root powers. The files are downloaded to the directory from which the apt-get source package command was called.


5.2 Packages needed for compiling a source package

Normally, specific headers and shared libraries need to be present in order for a source package to be compiled. All source packages have a field in their control files called 'Build-Depends:' that indicates which additional packages are needed for the package to be built from source. Some basic packages are also needed, check Downloading source packages, Section 5.1 before continuing.

APT has a simple way of downloading these packages. Just run apt-get build-dep package, where `package' is the name of the package you're going to build. For example:

     # apt-get build-dep gmc
     Reading Package Lists... Done
     Building Dependency Tree... Done
     The following NEW packages will be installed:
       comerr-dev e2fslibs-dev gdk-imlib-dev imlib-progs libgnome-dev libgnorba-dev
       libgpmg1-dev 
     0 packages upgraded, 7 newly installed, 0 to remove and 1  not upgraded.
     Need to get 1069kB of archives. After unpacking 3514kB will be used.
     Do you want to continue? [Y/n]

The packages that will be installed are the packages needed in order for gmc to be built correctly. It's important to note that this command doesn't download the source package of the program to be compiled. You will therefore need to run apt-get source separately to get it.

If all you want is checking what packages are needed to build a given package, there's a showpkg method for apt-cache command (see Getting information about packages., Chapter 6, which will show, among other informations, the Build-Depends line that lists those packages.

     # apt-cache showsrc package

5.3 Building a debuging package

If you want to build a package for debuging purposes to, for example, report a bug -- or fix one, you can use simple environment variables that are supported by most Debian packages.

To build a package which contains unstriped binaries[6] all you need to do is prefix it with DEB_BUILD_OPTIONS=nostrip. Optimizations can also make debuging harder, so you can disable them by adding the noopt string to the DEB_BUILD_OPTIONS variable too. Example:

     $ DEB_BUILD_OPTIONS="nostrip noopt" dpkg-buildpackage -rfakeroot -uc -b

5.4 Customizing package build options

If what you want is to customize the way the package is built you'll have to go about editing the debian/rules file. This means: inside the main directory created when the source package is extracted there will be a debian directory, which contains many files. One of them is special: the rules file.

This file is usually a Makefile that has targets to configure, build, install and create the package. For example, if I want to have the luola[7] built without sound I can, after downloading and extracting its source edit the debian/rules file that looks like this:

     [...]
     configure: configure-stamp
     configure-stamp:
     	dh_testdir
     	# Add here commands to configure the package.
     	./configure $(confflags) \
     		--prefix=/usr \
     		--mandir=share/man \
     		--infodir=share/info \
     		--datadir=share/games \
     		--bindir=games \
     		--enable-sound
     #		 --enable-sdl-gfx	
     
     	touch configure-stamp
     [...]

See the --enable-sound switch? If I remove it or replace it with --disable-sound and then rebuild the package using the technique described on Downloading source packages, Section 5.1 I'll have a luola package that is built with no sound.

If you really want to work with source packages on a daily basis I would suggest reading the Debian New Maintainers Guide and the Debian Policy, mainly. Other documentation available from the Debian Developers Corner may be useful too.


5.5 But hey, I do not want to use the Debian stuff!

Sometimes, people want to use a specific version of a program available only on source code, with no Debian package. But the packaging system can be a trouble when doing this. Suppose you want to compile a new version of your email server. All is fine, but many packages in Debian depend on an MTA (Mail Transfer Agent). Since you installed something you compiled by yourself, the packaging system doesn't know about it.

That's where equivs enters the scene. To use it, install the package with that name. Equivs creates an empty package that fullfills dependencies, making the package system believe that the dependencies are satisfied.

Before we begin, it is good to remind you that there are safer ways of compiling a program which is already packaged for Debian with different options, and that one should not use equivs to replace dependencies if she doesn't know what she is doing. See Downloading source packages, Section 5.1 for more information.

Let's continue with the MTA example, you just installed your new compiled postfix and goes on for installing mutt. Suddenly you discover that mutt wants to install another MTA. But you already have yours.

Go to some directory (/tmp, for example) and run:

     # equivs-control name

Replace name for the name of the control file you want to create. The file will be created as the following:

     Section: misc
     Priority: optional
     Standards-Version: 3.5.10
      
     Package: <enter package name; defaults to equivs-dummy>
     Version: <enter version here; defaults to 1.0>
     Maintainer: Your Name <yourname@foo.com>
     Pre-Depends: <packages>
     Depends: <packages>
     Recommends: <packages>
     Suggests: <package>
     Provides: <(virtual)package>
     Architecture: all
     Copyright: <copyright file; defaults to GPL2>
     Changelog: <changelog file; defaults to a generic changelog>
     Readme: <README.Debian file; defaults to a generic one>
     Extra-Files: <additional files for the doc directory, commaseperated>
     Description: <short description; defaults to some wise words>
      long description and info
      .
      second paragraph

We just need modify this to do what we want. Have a look at the field's format and at their descriptions, there's no need to explain each one here, let's look at an example instead:

     Section: misc
     Priority: optional
     Standards-Version: 3.0.1
     
     Package: mta-local
     Conflicts: mail-transport-agent
     Replaces: mail-transport-agent
     Provides: mail-transport-agent

Yes, that's all. mutt depends on mail-transport-agent, that is a virtual package provided by all MTAs, mta-local "registers" itself as an mail-transport-agent using the Provides field.

The Conflicts and Replaces fields are needed, too, so that APT and dpkg will understand they should remove the currently installed MTA package in favour of the new one you're installing.

Now you only need to build the package:

     # equivs-build name
     dh_testdir
     touch build-stamp
     dh_testdir
     dh_testroot
     dh_clean -k
     # Add here commands to install the package into debian/tmp.
     touch install-stamp
     dh_testdir
     dh_testroot
     dh_installdocs
     dh_installchangelogs
     dh_compress
     dh_fixperms
     dh_installdeb
     dh_gencontrol
     dh_md5sums
     dh_builddeb
     dpkg-deb: building package `name' in `../name_1.0_all.deb'.
     
     The package has been created.
     Attention, the package has been created in the current directory,

And install the resulting .deb. See Installing manually downloaded or locally created debian packages, Section 4.5.

As one can see, there are several uses for equivs. One can even create a my-favorites package, which depends on the programs you usually installs, for example. Just free your imagination, although being carefull.

It is important to note that there are example control files in /usr/share/doc/equivs/examples. Check them out.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ next ]


APT HOWTO

2.0.2 - October 2006

Gustavo Noronha Silva kov@debian.org