This site uses advanced css techniques
Many people install their software packages from vendor-supplied methods (RPM, up2date, apt-get, and the like), and this works for the most. But some of us are adamant about installing our internet-facing software from source obtained from the project mirrors, and over time we've developed what we believe are best practices in managing them.
The point of this Tech Tip is not to defend the practice of building everthing from source - we presume you've already decided that you want to, and are looking for advice - but we will touch on some of our reasoning;
We typically find a place - any place - on a filesystem with sufficient room for our package building, and /home/source is a common parking place. But because this varies from machine to machine, we always make a symbolic link to it so it's easy to find. We create the tarballs directory at the same time: this is where we park the packages we've fetched from the distribution servers:
# mkdir /home/source # mkdir /home/source/tarballs # ln -s home/source /source
Creating this place requires root privs, of course, but we normally do our source builds as a regular user, so we chown the whole tree to that user: chown -R username /home/source.
We use the excellent GNU wget tool to fetch each package, and from there we extract it to its own area. This example fetches Postfix:
$ cd /source/tarballs $ wget ftp://postfix.cloud9.net/official/postfix-2.0.12.tar.gz $ cd .. $ gtar -xzvf tarballs/postfix-2.0.12.tar.gz $ cd postfix-2.0.12 continue building
Just finding a place to park packages is not terribly difficult, but remembering how to build them is another story. Most packages these days use the configure tool, but these can take many parameters that often have to be adjusted as the package is explored.
Our practice has been to create a small shell script in the /source directory that contains the methods required to build the package. For instance, in the case of Postfix above, we had
make makefiles CCARGS='-DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ -DDEF_MAILQ_PATH=\"/usr/local/bin/mailq\" \ -DDEF_NEWALIAS_PATH=\"/usr/local/bin/newaliases\" \ -DDEF_SAMPLE_DIR=\"/etc/postfix/samples\" \ -DDEF_SENDMAIL_PATH=\"/usr/local/sbin/sendmail\" \ -DHAS_MYSQL -I/home/mysql/include/mysql' \ AUXLIBS='-L/home/mysql/lib/mysql -lmysqlclient'
Here we provided non-default installation directories that are to our liking, plus pointed Postfix at the location of the MySQL client libraries. To use these, we do
$ cd /source/postfix-2.0.12 $ sh ../configure-postfix $ make $ make test $ sudo make install
It's important that the configure-postfix script be kept in the parent of the Postfix source area, for two reasons.
Though Postfix here did not use the configure program, many do, and we can take one small additional step to make configuration a bit easier. When a new package is installed, go to that directory and populate the configure front-end with the configure --help output:
$ cd /source/mysql-4.0.13 $ ./configure --help > ../configure-mysql $ vi ../configure-mysql edit the file to add the actual configure code $ more ../configure-mysql exec ./configure \ --prefix=/home/mysql \ --enable-assembler \ --enable-local-infile \ --without-innodb \ --with-mysqld-user=mysql \ --with-unix-socket-path=/var/run/mysql/mysqld.sock `configure' configures this package to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. Defaults for the options are specified in brackets. .... the rest of configure help output $ sh ../configure $ make $ make test $ sudo make install
The help output itself is not executable - it's just a quick reference - and the exec just before the configure script name insures that the shell won't execute any of the documentation. The configure front-end script can also contain additional commentary, such as important pre-installation steps (such as creating specific system users or groups).
These front-end scripts show their further utility when a build need be done on some other system: copy the configure-whatever script to the new system and known-to-work parameters will be an excellent starting point even if machine-specific changes need be made. These scripts are a great place to leave notes for the next time, too.
Most of our thought goes into finding the proper options for ./configure, and after that it's usually smooth sailing. Setting compiler flags, pointing the tree to other required packages, and coordinating options with them. Once this has been done, the rest of the process is usually not much more than:
$ sh ../configure $ make $ make test or sometimes make check - see the makefile $ sudo make install
The final step, sudo, temporarily grants root privileges (assuming this has been explicitly configured by the system administrator) so that files may be copied to the proper places on the system. Those who build as root - not a very good idea - can just make install directly.