rpmproc use

actions

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.

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.

Supported tasks are currently:

  1. build (--build) for building a package
  2. local (--local) for uploading a package localy
  3. ftp (--ftp) for uploading a package remotely by ftp
  4. scp (--scp) for uploading a package remotely by scp
  5. mail (--mail) for announcing package changelog by mail
  6. clean (--clean) for cleaning package files

configuration

organisation

rpmproc read its configuration from following files:

  1. system-wide configuration /etc/rpmproc.conf
  2. user-wide configuration $HOME/.rpmprocrc
  3. any other file indicated by command-line option -c

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

A complete configuration dump can be obtained by command-line action --dump.

directives

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.

Most directives are self-explanatory, and are also commented in given configuration file. Some deserve however further explanation.

Target directory directives for local, scp and ftp tasks are designed to allow arbitrary splitting of package files. Each archicture can have its own TARGET_DIR_{ARCH} directive, which will only apply to files of given architecture. Source package are considered as src architecture in this regard. A default TARGET_DIR directive, if defined, will only apply to all other architectures.

Furthermore, any %{key} token in directive value will be expanded as the corresponding tag or macro defined in the spec file.

Exemples:

LOCAL_INSTALL_DIRECTORY=/home/guillaume/public_html/linux/jpackage/%{section}/%{name}
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.

FTP_INSTALL_DIRECTORY_SRC=./incoming
This will result in uploading only source files when using ftp

SCP_INSTALL_DIRECTORY_SRC=/home/plf/www/rpm/src
SCP_INSTALL_DIRECTORY_I586=/home/plf/www/rpm/cooker/i586
SCP_INSTALL_DIRECTORY_NOARCH=/home/plf/www/rpm/cooker/noarch
This will result in uploading source, i586 and noarch files in three different locations by scp.

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

for

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