On Sun, 2006-02-26 at 15:38 -0500, Warren Togami wrote:
My main thought here is, what does putting your buildroots on NFS
you? Do you realize that one of the main reasons beehive had failures
in past years was due to NFS problems?
Perhaps I should better explain what Clark and I are really doing, and
what we hope to gain by using mock so you can see where we are coming
from (and where we want to go). And no, I didn't realize beehive had
NFS problems since I've never used beehive...
Our group does embedded Linux ports, cross-compiling the specific
architecture on an x86 system. We don't do native compiles because we
typically don't create native compilers and the embedded systems are
typically quite slow.
For sometime we used a home-grown system of Makefiles and source
downloaded off the net. This system was quite fragile in several ways,
both at build time and at run time. We got frustrated with that system
and looked around for something else. I really wanted to use Fedora
SRPMS as a base to start with. I looked around and found an old system
that H.J. Lu had written to cross-compile part of RHL7.3 for mips.
Clark and I took that system and modified and extended it.
Here's how it currently works. We start with unmodified FCx SRPMs.
Each SRPM has a directory where we store our modified spec file (and
patches if necessary) to enable cross-compiling. We start with an empty
target arch buildroot and cross compile and install packages. As you
can imagine build order is quite important at first (for instance glibc
is one of the first packages we build). We build and install the
packages other packages need, then build the remaining packages. We
currently have about 120 or so packages in our distribution (typically
taking 4-6 hours to do a complete build).
Warren, you asked what does putting our buildroots on NFS gain us. I
guess the main answer is machine independence. We have several build
farm systems all mounting the same NFS shares. If a build system
becomes slow or goes down, I can just switch machines and restart the
build at the SRPM that died. Note that we don't support building
multiple RPMs simultaneously on the same buildroot (either on the same
machine or on multiple machines).
So, what do we hope to gain by using mock? We hope to make the cross-
compile porting process easier and we hope to gain even more machine
independence. Since our customers build on RHEL, part of getting the
packages to cross-compile entails getting the FCx packages to build on
RHELy. For instance, we build FC3 packages on RHEL3, FC4 packages on
RHEL4. Unfortunately, when we're done, we've typically mangled the
packages to only build on that version of RHEL (because of
autoconf/automake/etc. changes). If instead we built the FCx SRPM in a
mock FCx chroot, that part of the port effort wouldn't be needed. In
addition, if we're building in a mock FCx chroot, the host OS doesn't
Red Hat, Inc.