<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>rpmproc use</title>
</head>
<body>
<h1 align="center">rpmproc use</h1>
<h2>actions</h2>
<p>rpmproc is aimed at automatising and making easier several tasks
related to rpm management: building, uploading, etc... It is able
to perform any number of task for any number of package at
once.</p>
<p>rpmproc optimise processing by performing each task for every
package before switching to next one. This way, it uses only one
ftp connection, one rpm command, etc... Task order is fixed,
meaning cleaning will always occur last.</p>
<p>Supported tasks are currently:</p>
<ol>
<li>build (<strong>--build</strong>) for building a package</li>
<li>local (<strong>--local</strong>) for uploading a package
localy</li>
<li>ftp (<strong>--ftp</strong>) for uploading a package remotely by
ftp</li>
<li>scp (<strong>--scp</strong>) for uploading a package remotely by
scp</li>
<li>mail (<strong>--mail</strong>) for announcing package changelog
by mail</li>
<li>clean (<strong>--clean</strong>) for cleaning package files</li>
</ol>
<h2>configuration</h2>
<h3>organisation</h3>
<p>rpmproc read its configuration from following files:</p>
<ol>
<li>system-wide configuration <code>/etc/rpmproc.conf</code></li>
<li>user-wide configuration <code>$HOME/.rpmprocrc</code></li>
<li>any other file indicated by command-line option
<strong>-c</strong></li>
</ol>
<p>Redefinig an existing directive supersedes previous definition,
allowing easy configuration customisation. Morevoer, any number of
additional directives can be further redefined by command-line
option <strong>-w</strong>.</p>
<p>A complete configuration dump can be obtained by command-line
action <strong>--dump</strong>.</p>
<h3>directives</h3>
<p>All directive are name=value pairs, where name is capitalized
and prefixed by rpmproc task it is related (except for general
directive which are not prefixed). Binary directives admit 1 for
true, anything else for false. Multiple values directive use a
comma-separated list for values.</p>
<p>Most directives are self-explanatory, and are also commented in
given configuration file. Some deserve however further
explanation.</p>
<p>Target directory directives for local, scp and ftp tasks are
designed to allow arbitrary splitting of package files. Each
archicture can have its own <strong>TARGET_DIR_{ARCH}</strong>
directive, which will only apply to files of given architecture.
Source package are considered as src architecture in this regard. A
default <strong>TARGET_DIR</strong> directive, if defined, will
only apply to all other architectures.</p>
<p>Furthermore, any <strong>%{key}</strong> token in directive
value will be expanded as the corresponding tag or macro defined in
the spec file.</p>
<p>Exemples:</p>
<p>
<code>LOCAL_INSTALL_DIRECTORY=/home/guillaume/public_html/linux/jpackage/%{section}/%{name}</code><br>
This will result in uploading all files localy in a directory
whose name depends of the package name tag, itself located in a
directory named whose name depends of the package section
macro.</p>
<p><code>FTP_INSTALL_DIRECTORY_SRC=./incoming</code><br>
This will result in uploading only source files when using ftp</p>
<p><code>SCP_INSTALL_DIRECTORY_SRC=/home/plf/www/rpm/src</code><br>
<code>SCP_INSTALL_DIRECTORY_I586=/home/plf/www/rpm/cooker/i586</code><br>
<code>SCP_INSTALL_DIRECTORY_NOARCH=/home/plf/www/rpm/cooker/noarch</code><br>
This will result in uploading source, i586 and noarch files in
three different locations by scp.</p>
<p>scp doesn't allow uploading in non-existing directories, so the
scp task first upload everything in a directory whose existence is
ensured, then use a temporary script to complete installation. This
initial directory defaults to user home directory, but it is
sometimes preferable to use another directory, as on sourceforge
where quotas differs for user and group home directories. Thus the
need for <strong>SCP_CONNECTION_DIR</strong> directive.</p>
for
<p><strong>CLEAN_OLD_FILES</strong> directives for local, scp and
ftp try to figure in target directory which files correspond to
older versions/releases of the currently uploaded package. They
apply a set of regexp patterns, depending of current package
granularity. This means that if package granularity just changed,
and the subpackage -foo vanished, old -foo subpackage won't be
deleted.</p>
</body>
</html>
