Package dependencies

The Uyuni git repository contains code for multiple packages. For a release of a new version, the packages are tagged using tito. Tito increase automatically the version of the package during tagging.

This makes it difficult to define package dependencies. A dependency to a future version should be defined, but it would break the tests, as that version does not exist yet. This means defining such a dependency can only be done at the time of tagging.

Tito got now enhancement to read versions dependencies from a properties file and change the dependency during tagging - at the same time it also increase the version number.

To define a dependency a tito.props file should be created next to the spec file. The file has INI file format. The two sections [requires] and [buildrequires] are evaluated to define these kind of dependencies. The package name and minimal version are specified in these sections as simple key/value configuration.

Example java/tito.props:

[requires]
salt-netapi-client=0.18

[buildrequires]
salt-netapi-client=0.18

tito will do a replacement in the spec file for all Requires: salt-netapi-client and BuildRequires: salt-netapi-client to require minimal the version 0.18.

Add new Java dependencies or update existing ones

You would add it to ivy-suse.xml (with org="suse") and obs-maven-config.yaml (if there is a package available in IBS and/or OBS), then resolve the dependencies (ant -f manager-build.xml ivy) and you should get the jar file downloaded to your /lib folder.

Database schema dependencies

Some packages have a dependency to a minimal database schema version. E.g. java or python code which make use of a special table which was added with a specific schema version. As the database can run on a different system or container, a direct package dependency does not make sense. The service start script, which also check the correct DB version and automatically apply the schema upgrade was enhanced to also check the minimal required schema version.

Currently there are 2 packages which can define minimal schema version requirements: spacewalk-java via java/tito.props and spacewalk-backend via backend/tito.props.

Examples:

java/tito.props

[requires]
salt-netapi-client=0.18

[buildrequires]
salt-netapi-client=0.18

[dbschema]
conf/rhn_java.conf=4.2.10

backend/tito.props

[dbschema]
rhn-conf/rhn_server_xmlrpc.conf=4.2.10

These packages provide a config-defaults file, where we can set the minimal required schema version. Tito will change these versions according to tito.props during the tagging similar to the package dependencies. When this package gets installed and the startup script perform the schema check, it will read the minimal version from the config-default files, query the DB schema and compare the versions.

The database and all dependend services will not start when this requirement is not met.

TODO for Developers

When a code change is made which affect also the database schema, think about what will happen when you run this code with the old schema. If the change only works when this schema is applied, please specify the schema version which will have these changes in tito.props and add it to your pull request.

Also think about packages and libraries which are linked to packages you have changed. When you require a special version installed on the same system, check, if it makes sense to define a dependency to the minimal required package version.