SPMA with Yum as backend

28 August 2012

SPMA is the package manager in Quattor. Essentially, it is a framework that can use any package manager as its backend. However, the only real backend is based on direct invocations of the RPM library, and it cannot cope with the needs of a large site. As a result, package handling in Quattor is time consuming, and the largest source of problems for users.

So, this is a proposal for replacing the RPM backend with a Yum one.

Migration phase

In the first stage, repository and package resolutions in Pan will work just the same.

Package descriptions in Pan

In the first stage, descriptions of packages shall be identical. That is, they all must specify the version and the architecture.

In the future we may relax these requirements, and only enforce the name.

Repository descriptions in Pan

In the first phase, all packages must be listed in some repository template. This will allow the administrators to guarantee that all desired packages exist.

The current /software/repositories will become a list of Yum repositories to use. The SPMA-Yum backend will use it to populate /etc/yum.repos.d. At this stage, all repositories will be enabled, and no GPG key enforcing will be done.


When run with --noaction, Yum will just solve the transaction, but not execute it.


In this first stage, SPMA will not be able to revert all packages to a previous state. The second iteration will be able to use the history command.

Future developments

The following developments will follow shortly after:

History tracking and reverting

On systems where Yum’s history command is available, it will be possible to revert to a previous state. This will require to associate a Yum transaction ID with a Quattor tag.

Warning: If you actively clean up your repositories, you won’t be able to reproduce some points in your distant history.

Simplification of package specifications

The versions and architectures of all packages will become optional. If present, Yum will enforce them. If none is present, Yum will assume the latest version that satisfies all dependencies.

Repository descriptions

Repository descriptions will become closer to Yum’s. We will allow to define GPG keys, choose whether they should be enforced, which repositories will be disabled…

Backwards-incompatible changes

None is foreseen. Some fields may change names in the distant future.

New dependencies

The new component will depend on yum, yum-utils and yum-versionlock, in recent enough versions.

The old spma and rpmt-py packages become obsolete with the new component.