Automate NetBSD Package Builds





Automate NetBSD Package Builds

figs/expert.gif figs/hack87.gif

Use a sandbox to build applications that play nicely within your network.

Many NetBSD users are responsible for multiple systems running on different architectures. Instead of rebuilding the same package on machine after machine, it's often desirable to build packages for all of these machines from the most powerful one, delivering the appropriate binary packages across the network. However, problems can arise when not all machines run the same version of NetBSD or when you want different optimizations or build settings on each box.

The solution to this dilemma is simple: create a sandbox with the version of NetBSD used in the target machine and build the necessary binary packages inside it. This sounds easy, but it can be a very tedious and error-prone task. It is even more complex if you want to automate periodic package rebuilding. Fortunately, that's our final goal in this hack.

To simplify things, I assume that you have a relatively fast desktop machine running NetBSD-current, where you will build binary packages, and a server machine running the stable version of NetBSD (1.6.2 at the time of this writing).

1 Installing pkg_comp

pkg_comp (also known as Package Compiler) can simplify the creation of these sandboxes: it handles any version of NetBSD inside a chroot jail and automates the build process of binary packages inside it. Its only restriction is that both the builder and the destination machine share the same architecture.

Let's begin by installing pkg_comp on the builder machine (make sure you have Version 1.15 or greater):

# cd /usr/pkgsrc/pkgtools/pkg_comp

# make install && make clean

After installation, spend some time reading man 8 pkg_comp and getting familiar with its structure because you will be using it as a reference guide during the configuration. Also ensure that your kernel configuration file contains file-system NULLFS. (See man 4 options for more information.)

2 Configuration Variables

Now you are ready to set up pkg_comp. The configuration file tells pkg_comp how to create the sandbox. Type the following commands to create and edit a sample configuration file:

# pkg_comp maketemplate

# vi /root/pkg_comp/default.conf

You will notice lots of variable definitions. All you need to do is set some values; pkg_comp handles everything else. For our purposes, you need to know only some of these variables (see Figure) and change them to suit your system.

pkg_comp variables

Variable

Usage

DESTDIR

Gives the location of the sandbox. This needs lots of disk space, as it will store a complete NetBSD system. In this example, use /var/chroot/pkg_comp/default.

DISTRIBDIR

The location of NetBSD installation sets, whether downloaded from the FTP site or built using build.sh. pkg_comp. The /binary/sets string will be appended to the value you provide. The resulting directory should contain the files listed in the SETS and SETS_X11 variables. In this example, use /home/NetBSD/NetBSD-1.6.2/i386.

NETBSD_RELEASE

Specifies the version of NetBSD to unpack in the sandbox. This version must be compatible with pkgtools/libkver. If you leave it set to no, pkg_comp assumes the builder system and the sandboxed system are the same version. In this example, its value is 1.6.2.

REAL_SRC

Provides the location of pkgsrc distfiles. In this example, use /home/NetBSD/distfiles.

REAL_PACKAGES

Identifies the destination of binary packages. In this example, use /home/NetBSD/packages/1.6.2.

REAL_PKGSRC

Locates the pkgsrc tree in your system. In this example, use /usr/pkgsrc.

REAL_DISTFILES

Gives the location of the NetBSD source tree in your system. In this example, use /usr/src-1.6. Because we are building for 1.6.2 and the builder is running current, this will not be /usr/src.

SETS

Lists the NetBSD sets to be extracted inside the sandbox. Do not change the default value.

SETS_X11

Lists the X11R6 sets to be extracted inside the sandbox. Set this to no if you do not want to build packages for the X Window System, but avoid modifying the default list. In this example, set it to no, since I assume you do not have the X Window System installed on the server.

REAL_PKGVULNDIR

The location of the pkg-vulnerabilities file in your system. In this example, use /usr/pkg/share. If you are not using audit-packages, then set USE_AUDIT_PACKAGES to no. The use of audit-packages is strongly encouraged because it won't install packages that have known security problems.


Now is the time to enable compile-time optimizations for the packages you are going to build. As you modify the CFLAGS and CXXFLAGS variables, keep in mind that the configuration file is a shell script. Remember to quote your values properly.

3 Initializing and Using the Sandbox

After setting your values and creating all of the referenced directories, it's time to initialize the sandbox. It is as easy as typing:

# pkg_comp makeroot

When this command finishes, the sandbox is ready to build packages for your server. In this example, the packages will linked against 1.6.2 libraries using any specified optimizations.

Suppose you want binary packages for Apache and screen. Compile them with the following call to pkg_comp:

# pkg_comp build www/apache misc/screen

This will place apache-1.3.29.tgz and screen-4.0.2.tgz—as well as their dependencies—under /home/NetBSD/packages/1.6.2/All. They're now suitable for transferring to the destination machine. Install them with pkg_add.

If you do not need to build more packages using pkg_comp, you can safely free the space used by the sandbox with the command shown next. Note that this removes only the sandbox, not binary packages:

# pkg_comp removeroot

4 Automating the Process

We can go one step further and configure pkg_comp to create the sandbox, build a predefined set of packages for your server, and remove the sandbox when finished, all automatically. This takes only a single command with pkg_comp's automatic mode.

To enable automatic mode, re-edit the configuration file, /root/pkg_comp/default.conf, and define the AUTO_PACKAGES variable. This variable takes the list of packages you want to build for your server. In this example:

AUTO_PACKAGES="misc/screen www/apache"

That's it for the configuration side. To check if this works, make sure the sandbox does not exist, and execute pkg_comp's automatic mode:

# pkg_comp removeroot

# pkg_comp auto

After a while, you will find binary packages for screen and Apache in your package repository, just as in the earlier example.

If the list of packages is extensive, the build will take a long while, which may not be desirable in some environments (for example, in cases when you need to shut down the builder during the night). This is not a problem: if you stop the automatic process with Ctrl-c at any point, you can resume it later by issuing:

# pkg_comp auto resume

To finish the automation, configure a cron job to rebuild your package set automatically once a week. Edit root's crontab to add the line:

# crontab -e

0       3       *       *       *       /usr/pkg/sbin/pkg_comp auto

5 Hacking the Hack

I've shown the most basic usage of pkg_comp in this hack. If you found it useful, there are many more things to learn, and the manpage is a good starting point.

Here are some other ideas to try:

  • Configure a cron job to rebuild all the packages you need for your own machine, so that you can easily restore them at any point with pkg_add.

  • Create two configuration files with different names.

  • Enable GCC 3 with extensive optimizations.

6 See Also

  • man pkg_comp

  • man pkg_add


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows