On Fri, 2006-02-24 at 18:10 -0500, Dan Williams wrote: I didn't mean to imply that I'm not confident of my ability to *use* bind mounts, just that I'm suspicious of remounting a network filesystem. Fifteen or so years of wrestling with NFS have made me leery of layering anything on top of it. The main reason I'd like to have an arbitrary location for buildroots is that in our farm system, multiple builds may be occurring on a compile host at the same time (e.g. one person building for a MIPS and another building for ARM). Having them both collide in /var/lib/mock wouldn't be fun. Since each architecture has it's own space on the NFS server (which is connected via gigabit ethernet to the compile systems), if you stay in your own sandbox, you don't collide with anyone else. I'm not sure I want to use mock in the same way it's used by Plague (i.e. clean the chroot, populate it, build one package). Since we currently use a custom set of rpmmacros, rpmrc and a few command line definitions to cross-build our RPMs, I'd rather use mock to setup one chroot for an architecture and then build multiple packages out of it. I'm not certain of that now, but that's the way I'm leaning. Clark -- Clark Williams <williams(a)redhat.com&gt;

will the rpmdb's get created properly on nfs? I thought they went a bit nutty? you should look at the mock config file - you can put your rpmmacros and rpmrc specifications in to the config file and it will be pushed into the chroot automatically. -sv

The fhs is our friend. :) However I don't think we're suggesting changing the default location for mock just making it possible for someone else to do something like that. And if we can do that securely then, sure. -sv

On Sun, 2006-02-26 at 15:38 -0500, Warren Togami wrote: Warren, 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 really matter. -- David Smith dsmith(a)redhat.com Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)