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.
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.
/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
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 will become closer to Yum’s. We will allow to define GPG keys, choose whether they should be enforced, which repositories will be disabled…
None is foreseen. Some fields may change names in the distant future.
The new component will depend on
yum-versionlock, in recent enough versions.
rpmt-py packages become obsolete with the new