bugzilla #164441 (mock-helper and basedir)

[David Smith]

On Sun, 2006-02-26 at 11:01 -0500, seth vidal wrote:
> > 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.
> 
> will the rpmdb's get created properly on nfs? I thought they went a bit
> nutty?

I work with Clark so I'll throw in a bit here.

Storing a rpmdb on NFS does OK for awhile, then goes wonky (hope that's
not too technical for you ;-).  Since our target rpmdb's were fairly
transitory, it wasn't a huge deal,  just annoying.  It finally got *too*
annoying one day and I found a workaround (with the help of every
programmer's friend - google).  I added the following to our rpmmacros
file:

# We're adding the private token.  This should help when storing the db
# on a NFS file system.
%__dbi_other		%{?_tmppath:tmpdir=%{_tmppath}} %{?__dbi_cdb} \
				private


Adding 'private' to %__dbi_other causes rpm to use the DB_PRIVATE flag.
Here's a description of DB_PRIVATE from
<http://www.sleepycat.com/docs/ref/env/region.html>:

=================================
If the DB_PRIVATE flag is specified to the DB_ENV->open method, regions
are created in per-process heap memory; that is, memory returned by
malloc(3). 

This flag should not be specified if more than a single process is
accessing the environment because it is likely to cause database
corruption and unpredictable behavior. For example, if both a server
application and Berkeley DB utilities (for example, db_archive,
db_checkpoint or db_stat) are expected to access the environment, the
DB_PRIVATE flag should not be specified.

...

If no memory-related flags are specified to DB_ENV->open, memory backed
by the filesystem is used to store the regions. On UNIX systems, the
Berkeley DB library will use the POSIX mmap interface. If mmap is not
available, the UNIX shmget interfaces may be used instead, if they are
available.
=================================

After adding "private", our use of rpmdbs on NFS has been rock-solid.
(However, your mileage may vary.)

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

Hmm, didn't know you could specify different rpmmacros and rpmrc files
in the config file.  I'll look into that.  The only hold up for us might
be that we do both native and cross compiles during our full builds and
we normally use different rpmmacros/rpmrc files based on what we're
compiling for.

-- 
David Smith
dsmith at redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)