On Fri, 2006-02-24 at 22:38 -0600, Clark Williams wrote:
On Fri, 2006-02-24 at 18:10 -0500, Dan Williams wrote:
> I can't speak for Seth, but I'm fairly sure the answer here is "use
> mounts". Seth is very big on the FHS, and in the FHS, that's where the
> buildroots and other stuff for mock are supposed to live. I've asked
> about this long ago, when starting to use mock for the build system, and
> that was the answer. Seriously, bind mounts are neither complicated,
> nor problematic, though I haven't done a ton of testing with NFS.
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 other question is why you want the buildroots on NFS in the first
> place. Unless you have blazingly fast storage, it's likely that local
> SCSI disk will be quite a bit faster than NFS. Since creating buildroot
> and doing the actual builds involves _quite_ a lot of IO, the same issue
> applies; local storage is likely better unless you've got really a fast
> path to the shared storage.
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.
Ok; if you want different directories for different architectures, there
are two ways to do it:
1) in the mock config file for the target, change the 'root' option to
include your architecture. Then pass '-r <target>' on the mock command
2) use the --uniqueext=<unique extension> option on the mock command
line to futher unique-ify your buildroot