bugzilla #164441 (mock-helper and basedir)

Clark Williams williams at redhat.com
Sat Feb 25 04:38:29 UTC 2006


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 bind
> 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.

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 at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-buildsys-list/attachments/20060224/f756c550/attachment.sig>


More information about the Fedora-buildsys-list mailing list