OBS Repositories and Docker Builds: Deterministic Dependency Resolution for openSUSE Leap Environments

Answer to the core questions

1. Does a changing metadata timestamp alone alter zypper’s solver output when RPM NVRA values stay the same?

Zypper’s solver is deterministic with respect to the exact set of available RPMs. If the epoch:version:release (NVRA) of every package is unchanged, varying timestamps in the repository metadata do not influence which packages are selected. The solver only looks at the available NVRA set and the dependency graph, not at the age of the metadata files.

2. What Docker build tweaks must handle OBS auto‑rebuilds that keep the same NVRA?

• Pin the repository to a static snapshot URL or a local mirror that does not change until you intentionally update it.
• Force a metadata refresh in the Dockerfile (e.g., zypper refresh -f) so the build always pulls the latest metadata from the snapshot, not from a cached layer.
• Disable Docker’s layer caching for the steps that touch the repository: either use --no-cache or add a --pull flag combined with a --build-arg that changes when you want a new snapshot.
• Optionally, include a --build-arg REPO_SNAPSHOT_URL that the Dockerfile passes to zypper addrepo to reference a specific snapshot URL.

3. Is a zypper lockfile enough to keep installations identical across mirror syncs?

No. A lockfile (via zypper lock or files in /etc/zypp/locks) prevents upgrades to newer NVRA values, but it does not guard against OBS publishing a new binary build that has the same NVRA but a different payload checksum. The solver will still see the same NVRA and install it, even if the underlying RPM has changed.

Practical steps for a reproducible Docker image

# Dockerfile snippet for openSUSE Leap with OBS snapshot
FROM registry.opensuse.org/leap/15.6/base:latest
ARG REPO_SNAPSHOT_URL
ARG REPO_GPG_KEY

# Install zypper and refresh metadata from a fixed snapshot
RUN zypper --non-interactive install -y curl gnupg && \
    curl -L -o /etc/zypp/repos.d/obs-snapshot.repo ${REPO_SNAPSHOT_URL} && \
    zypper --gpg-auto-import-keys refresh -f && \
    zypper --non-interactive install -y myapp

# Optional: lock the installed packages to avoid accidental upgrades
RUN zypper lock -p \
    <package-names>

Verification checklist

1. Build two images from the same Dockerfile, one with --no-cache and one with the default cache.
2. Run rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' inside each container and compare the sorted lists.
3. For a package that is known to be auto‑rebuilt, compare rpm -qi <pkg> | grep -i checksum to confirm that the payload differs while the NVRA stays the same.
4. Check that a lockfile prevents any upgrade to a newer NVRA but does not stop the binary from changing when the source version is unchanged.

Key take‑aways

• Metadata timestamps alone do not break determinism.
• Use a fixed snapshot URL or local mirror to avoid mirror drift.
• Force metadata refresh and disable layer caching for repository steps.
• Lockfiles guard against version bumps but not against binary changes with the same NVRA.
• Always verify the final image contents and checksums when reproducibility is critical.