At 2004-09-13T16:52:56+1200, Jim Cheetham wrote: > What's the *right* way to rebuild a Debian package with different > options?
> i.e. they ship with Exim, but it doesn't have MySQL support (there are > other answers possible, but this is an example, not a problem) > I'd like to recompile the shipped Exim with different options, and > then install properly (i.e. with dependencies if possible). But I > suspect I'll be caught out when an upgrade happens, won't I? Well, in general the first thing to do is check for alternate versions of the package in the official Debian archives. Using exim as an example there are two builds of the exim4 daemon are available in 'testing': a "light" and "heavy" build. The "heavy" build contains support for most of exim's optional features, whereas the "light" build provides only what's necessary for a simple MTA installation. I realise that this doesn't answer your question, but usually you're better off using an official Debian package if one is available. If no package is available that suits your needs, you're forced to build from source. In this case, it's usually best to build it "the Debian way" and have the from-source package managed by the package system. Building a Debian package from source is fairly simple. Make sure you have deb-src entries in your sources.list, then: # Get the build dependancies $ apt-get build-dep <package> # Prepare the source $ mkdir <package>; cd <package> $ apt-get source <package> $ cd <package>_<version>-<revision> # Tweak the debian/control file and any configuration you need to at # this point. Note that you can't just run ./configure --some-new--opt # and assume the package will be build with this option--you'll need to # location the rule in the debian/rules file that runs the configure # process and make the appropriate changes there. # Build the package and install $ dpkg-buildpackage -rfakeroot -b -nc $ dpkg -i ../<package>_<version>-<revision>_<arch>.deb Before you build from source this way, you need to decide how you're going to ensure the newly built package is not overwritten by an official Debian package during an upgrade. There are a few options available to allow this: you can put the new package on hold once it's installed (ensuring it is not upgraded automatically), you can alter the version epoch to ensure an official Debian package is unlikely to appear to be 'newer' to the package management system, you could 'pin' the package into a local repository to ensure that any automatic upgrade of this package will only be sourced from a local repository, etc. Once you take responsibility for building packages in this manner, you also take responsibility for updating them if bug fixes, security fixes, etc. come along. This means you need to either keep an eye on the official Debian package you based your package on, or follow the upstream development of the software. Depending on your needs, you could probably get away with automating this somewhat by writing a script to watch for updates to the official Debian package, downloading the updating source, and then emailing the admin advising them to build an updating package. In short, to do this properly, you need to learn a fair amount about how to be a Debian package maintainer, which can be a fairly big job in itself. If you still want to go down this route, read the references below to get a better understanding of what's involved. > Gentoo? This is the sort of thing that Gentoo appears to make somewhat easier. [0] http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html [3] http://www.debian.org/doc/manuals/debian-faq/ch-customizing.en.html#s-localpackages [1] http://www.debian.org/doc/manuals/maint-guide/index.en.html [2] http://www.debian.org/doc/manuals/developers-reference/index.en.html Cheers, -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
