The Quasix Philosophy and RPM

Why use RPM?

We use RPM because the LSB recommends it. RPM's macro system also
provides a lot of control over every stage of the build process.

General Guidelines

Subpackages (or lack thereof)

Since Quasix is a system for developers, or for people who like to compile
everything on their system, it makes no sense to break packages up into devel
or lib subpackages. So, every RPM built for Quasix will initially include
all the files of a package had the source been built without RPM. Unnecessary
files will be removed as required.

Dependency Hell (or is it?)

A lot of headaches for the user and the developer can be eliminated by simply
letting RPM do its thing with dependencies. Often RPM's default output is not
desirable because it is TOO descriptive and makes the process of manually
determining dependencies of a given package pretty much impossible. This
situation is best handled by an external application. Simple shell scripts
handle dependency resolution with ease and let RPM do what it does best -- keep
track of what and when/where things are installed, what files are needed to
install/run a given package, and verifying package integrity.

Scripting Large Builds

It's easy to see that by adding one macro to RPM, we can exert a lot of control
over building several RPMs at once from a centralized location. We've abstracted
a lot of the dependency details from the specs and now have the option to control
the dependencies externally or let RPM handle them. Below is an example script
and some configuration files:

#!/bin/sh
# Build script

CONFIG="config.rpm"
PKG_DIR=`rpm --eval %_rpmdir`
SRC_DIR=`rpm --eval %_sourcedir`
IFS=':'
cat ${CONFIG} | while read NAME VERSION; do
  rpm -q ${NAME}-${VERSION} 2>1 >/dev/null
  if test ${?} -ne 0; then
    rpmbuild -ba --clean ${SRC_DIR}/${NAME}.spec || exit 1
    sudo rpm -i ${PKG_DIR}/${NAME}-${VERSION}*.rpm
  fi
done

# End script

# Begin config.rpm
openssl:0.9.7
elinks:0.9.0
# End config.rpm

Now it's pretty clear that the dependencies are being set initially by the
order of config.rpm. Given the current state of packaging systems,
human intervention is advised when determining the build order of the whole
distribution, if only just to save time. Obviously if one wanted openssl
support in elinks, they'd build and install openssl before installing elinks.

Quasix Home