I'll use GDB as an example of how to build your own package - for a good reason, firstly because the stock version of GDB that is shipped with Ubuntu is terribly broken. Here's what I mean:
% gdb --args java
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
(gdb) r
Starting program: /usr/bin/java Test
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New process 16487]
Executing new program: /usr/lib/jvm/java-6-openjdk/jre/bin/java
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
[New process 16487]
[Thread debugging using libthread_db enabled]
Segmentation fault
The stock build of GDB doesn't handle multi-threaded applications properly, among other minor issue like not setting the path to point to the correct debug library paths, which makes it unusable for serious debugging tasks.
Secondly, GDB 7.0 has reversible debugging, which makes it doubly tempting to roll my own. Finally, GDB has minimal external and library dependencies, which is an easy example to build a package without going into the complexity of having to generate a
chroot
ed environment.But why not just do the typical
'configure && make install'
combination?The drawback in doing so, is that the process is one-way: once you've installed it like that, there is no easy way of uninstalling it, short of remembering the list of what's being installed and removing them manually. Do-able? Sure, but certainly cumbersome. The neater way to do this is to create a package and have the package manager deal with installation/uninstallation for you.
Building GDB
We need to perform the usual compiling and installing steps like we normally do; the only difference is that we want the installer to place all the resultant files into a separate directory for generating a package. Doing this is straightforward using the prefix flag provided by
configure
. The steps are commented and reproduced below:
# Assuming that you're in the current source directory /home/user/gdb-sources
% mkdir -p custom-gdb-7.0-amd64/usr/
% configure --prefix=/home/user/gdb-sources/custom-gdb-7.0-amd64/
% make && make install
There are dependencies that GDB will need in order to compile properly (things like bison, lex as far as I remember), but I'll assume that you know how to resolve these dependencies yourself. Otherwise, the source should finish compiling and installing to the destination
/home/user/gdb-sources/custom-gdb-7.0-amd64/
.Generating the Control file
In order to generate a package, a Debian control file is required, which contains the information that the 'dpkg-deb' package generator will need. Here's how we write one:
% mkdir custom-gdb-7.0-amd64/DEBIAN
% cat > custom-gdb-7.0-amd64/DEBIAN/control
Package: customgdb
Version: 7.0
Section: base
Priority: optional
Architecture: amd64
Depends: lex, bison
Maintainer: Vincent Liu<blog@vinceliu.com>
Description: Custom build of GDB
This version of GDB provides cutting edge
capabilities that the stock package does not provide.
^D
%
# The control-D symbol above is to indicate the
# file termination character
There are plenty of details I've omitted here, and you will have to read more to understand and tune your own control file configuration. Here's the tutorial I referenced, and the Debian manual to help you figure out the details of each control field.
Generating and Installing the Package
Once you've got the control file generated, building the package is just a single
dpkg-deb
away:
% fakeroot dpkg-deb --build custom-gdb-7.0-amd64
You will get a resulting
custom-gdb-7.0-amd64.deb
package generated for installation. To install it, you'll have to remove the existing GDB package, as it conflicts with your new installation. Do the following:
# remove the original gdb
% dpkg -r gdb
# install the new gdb
% dpkg -i custom-gdb-7.0-amd64.deb
If you ever needed to revert back to the stock versions of GDB, you can now easily remove your custom version by
dpkg -r customgdb
, and reinstalling it using apt-get
or your own favourite package manager.
2 comments:
Thanks - clear and concise and clears any fears that it might be more difficult than building an RPM, which seems to be much more easily and clearly documented. Good work!
Thanks for the guide!
When I went to remove my stock GDB with my package manager, it also wanted to remove Ubuntu's "apport" bug-reporting utility because "apport" depends on GDB. I wonder if I could've avoided that by configuring my custom GDB with "--program-suffix=SUFFIX (append SUFFIX to installed program names)" and installing it /alongside/ the stock GDB.
I also removed the "lex" dependency from the control file. It was giving me grief about a pseudopackage or something.
Keep up the good work,
-Tyler (http://unsyncopated.com)
Nitpick: "configure" => "./configure"
Post a Comment