Subject: Re: Has anyone tried building -current as non-root from scratch recently?
To: Simon Burge <firstname.lastname@example.org>
From: David Querbach <email@example.com>
Date: 03/26/2001 11:10:24
> This doesn't help cross-compiles. A better solution is to have a
> generic userland tool to build filesystem images so that there are
> no kernel dependancies at all. This is part of the "There's work
> in progress..." bit that Luke mentioned.
We've developed a set of scripts for non-root cross-builds which use generic
tools. They're to the point that we use them daily for generating nfs-root
mountable file systems for cross-development.
We're interested in people's thoughts on our approach, so I'll outline it
Our design criteria were:
1. The user running the build is trusted -- he knows the root password on
the build machine. The reason for the non-root build is not so much
security as convenience and disaster-avoidance.
2. Changes to the existing build system should be minimized.
3. The source and object directories should be owned by the normal user.
4. The files in DESTDIR should have all of the proper ownerships and
privileges. The resulting directory should be directly NFS-root
5. Building for multiple targets from the same source directory should be
With our system, one can simply go into a directory in the source tree and
do, for example,
xmake -M <machine> all install
MACHINE=<machine> xmake all install
or in certain circumstances simply
xmake all install
and the result will be a non-root make and a privileged install to the
<machine>'s DESTDIR. However, since only the DESTDIR manipulations are run
with root privileges, the source and object directories are all owned by
normal user, which we find far easier to work with.
The actual mechanism we use is:
1. A script `/usr/pkg/cross/bin/xmake' expects either an argument `-M
<machine>' or an environment variable `MACHINE=<machine>' to determine the
This parameter also chooses among configuration files with names
/usr/pkg/cross/libexec/xmake/<machine>.xmk. These configuration files
perform part of the function of /etc/mk.conf.
2. The `xmake' script puts /usr/pkg/cross/libexec/xmake at the head of
the user's execution PATH.
This directory holds about a dozen small scripts which intercept
invocations of the programs required to install the system. (These
scripts currently include chgrp, chmod, chown, config, cpio, install,
install-info, ln, makewhatis, mknod, mtree, mv, pax, rm, and zic.)
As an example, the `install' script contains:
sudo-if-destdir /usr/bin/install "$@"
The `sudo-if-destdir' script also lives in /usr/pkg/cross/libexec/xmake:
utility=$1 ; shift
if [ "$(echo $(pwd -P) $* | grep $DESTDIR 2>/dev/null)" ]; then
sudo $utility "$@"
This script captures the name of the utility (/usr/bin/install in this
example) and runs it under `sudo' if and only if either the current
directory is DESTDIR or one of the command line arguments refers to
There are a few other details which allow for things like per-project
replacement of etc/mk.conf, and default values for <machine> and DESTDIR,
but they are not crucial to the above mechanism.
Our approach requires only a very small number of changes to the existing
build system. Most of the changes simply remove absolute paths from
invocations of the above-mentioned utilities so the xmake scripts can
intercept the calls.
Only a single program, the game `phantasia', does not build under our system
because it creates its own installer which wants to write directly to
DESTDIR. This shouldn't be hard to fix, but we haven't taken the time to do
Does this seem like a reasonable approach? If so, we could perhaps make a
package of it for inclusion in pkgsrc.
Real-Time Systems Inc.