Updating container dependencies

This is the most common container image operation – more frequent than creating new images.

Adding an RPM dependency

1. Add the package name to builds/<name>/rpms/rpms.in.yaml under packages:.

2. If the package is only needed at build time (e.g., gcc, python3-devel), tag it with # builddep.

3. Regenerate the RPM lockfile:

   make builds/<name>/rpms/rpms.lock.yaml
   

4. If the new RPM provides a Python package that’s also in the Python lockfile, add --no-emit-package=<python-name> to the per-image requirements.lock header and regenerate it. Add #include "verify-python-lockfiles" to the Containerfile if not already present.

Adding a Python dependency

1. Add the dependency to pyproject.toml (under the appropriate extras group).

2. Regenerate the root lockfile first:

   make requirements.lock
   

3. Then regenerate the per-image lockfile:

   make builds/<name>/requirements.lock
   

4. Order matters: the root lockfile is the constraint source for per-image lockfiles.

Updating existing dependencies

• Routine updates are handled automatically by Renovate. No manual action needed.
• Force an immediate update: regenerate the relevant lockfile(s) via make targets.
• Pin a specific version: add a version constraint in pyproject.toml or rpms.in.yaml, then regenerate.

The # builddep marker

Packages tagged with # builddep in rpms.in.yaml are marked as build-only dependencies. The cleanup include runs dnf autoremove which removes them (along with their transitive deps) from the final image.

Use for: compilers (gcc), development headers (python3-devel, *-devel), build tools (git-core when only needed for VCS pip installs).

Lockfile regeneration prerequisites

• Requires dependency-tools:production image (pulled automatically by Makefile PODMAN_RUN macro).
• Uses a cache directory (default /tmp/rpm-lockfile-cache) for DNF metadata; the Makefile creates it via an order-only prerequisite.
• See Lockfiles for full details on the Makefile pattern and header format requirements.