PkgForge-Server

 view release on metacpan or  search on metacpan

doc/admin/mock.html  view on Meta::CPAN

disk space (probably at least 20GB but it depends on the number of
different chroots you use). By default the packages are built in
sub-directories of <code>/var/lib/mock/</code> and the cached chroots
are stored in <code>/var/cache/mock</code>. Both of these locations
can be changed in the <code>/etc/mock/site-defaults.cfg</code>
configuration file.</p>

<p>The PkgForge builders have a concept of a
package <em>bucket</em>. Basically this is the directory into which a
package will be submitted once it has been successfully built. It
normally makes sense to ensure that the dependencies for packages are
resolvable within certain sets of buckets. For example, we aim to
ensure that packages in our publically-accessible <em>lcfg</em> bucket
do not have dependencies that can only be resolved from our
restricted-access local buckets (e.g. <em>inf</em>
and <em>uoe</em>). To ensure this happens mock must have a different
chroot for each package bucket on each platform and each
architecture. The PkgForge builders expect to find mock chroot
configurations named
like: <em>platform</em>-<em>bucket</em>-<em>architecture</em>. This
normally means configuration files named
like <code>/etc/mock/f13-world-i386.cfg</code>.</p>

<p>Most of the configuration for a chroot is actually for yum. As an
example, here are the mock configuration options for a Fedora 13 i386
chroot for the <em>world</em> bucket. The syntax is python so some
care has to be taken to ensure you do not completely break mock when
it loads the file.</p>

<pre>
config_opts['root'] = 'f13-world-i386'
config_opts['target_arch'] = 'i686'
config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build'
config_opts['dist'] = 'f13'  # only useful for --resultdir variable subst
config_opts['resultdir'] = '/disk/scratch/mock/results/world/f13'

# ccache not available on epel5
config_opts['plugin_conf']['ccache_enable'] = True
</pre>

<p>The two important bits here are the <em>resultdir</em> and
the <em>chroot_setup_cmd</em> options. The results directory should
point to somewhere with sufficient space and should be a different
directory for each platform/architecture/bucket combination to keep
everything sane. The setup command is passed to yum and is what
installs the initial set of build-dependencies.
The <em>buildsys-build</em> package group contains all the essential
build-dependencies which are not normally specified in a specfile.</p>

<p>The following is the yum configuration for the previous example:</p>

<pre>
config_opts['yum.conf'] = """
[main]
cachedir=/var/cache/yum
debuglevel=1
logfile=/var/log/yum.log
reposdir=/dev/null
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1
metadata_expire=60

#repos

[f13base]
name=f13base
baseurl=http://http.pkgs.inf.ed.ac.uk/sites/f13/Everything/i386/os
enabled=1
gpgcheck=0

[f13updates]
name=f13updates
baseurl=http://http.pkgs.inf.ed.ac.uk/sites/f13/updates/i386
enabled=1
gpgcheck=0

[f13world]
name=f13world
baseurl=http://http.pkgs.inf.ed.ac.uk/rpms/layers/world/f13
enabled=1
gpgcheck=0

[f13lcfg]
name=f13lcfg
baseurl=http://http.pkgs.inf.ed.ac.uk/rpms/layers/lcfg/f13
enabled=1
gpgcheck=0

[local]
name=local
baseurl=file:///disk/scratch/mock/results/world/f13
enabled=1
gpgcheck=0

"""
</pre>

<p>The <em>main</em> configuration is pretty much standard. The
important bit is to ensure that the <em>metadata_expire</em> option is
sufficiently low that yum will reload the metadata for every
build. This allows builds to depend on packages generated by previous
builds. After that the rest are the required yum-enabled package
repositories which can be used to install build-dependencies.</p>

<p>Beyond that, the only other really important bit to note is
the <em>local</em> repository. This makes it possible to use packages
built using this chroot during this run as build-dependencies for
subsequent builds. To do this the <em>createrepo_on_rpms</em> option
must be set to <code>True</code> in the <code>site-defaults.cfg</code>
file. This does sometimes cause problems with file permissions when it
comes to the PkgForge builders cleaning out a results directory before
doing a new build. To get around this issue
the <em>createrepo_command</em> option in
the <code>site-defaults.cfg</code> file should be set
to <code>/usr/sbin/createrepo_hack</code>. The hack script is a pretty
simple wrapper around the real <code>createrepo</code> command:</p>

<pre>
#!/bin/bash

dir=$1

/usr/bin/createrepo -d -q -x '*.src.rpm' $dir
retval=$?

if [ "$EUID" -eq 0 ]; then
   chmod -R g+w $dir
fi

exit $retval
</pre>

<p>This script is normally run as root so it can fix up the group-mode
on all the files and directories in the tree.</p>

<h2>Using LCFG</h2>

<p>The simplest method of configuring all the mock chroot files is to
use the LCFG mock component. Here is an example for SL6, see the
lcfg-mock(8) manual page for full details of the available
resources.</p>

<pre>
#include &lt;lcfg/options/mock.h>

!mock.basedir                mSET(/disk/scratch/mock)
</pre>

<p>That sets up the defaults and the necessary PAM configuration. Only
one global change is made and that is to the mock base directory so a
separate partition can be used. Next is to create the full list of
available repositories:</p>



( run in 0.607 second using v1.01-cache-2.11-cpan-df04353d9ac )