Open Build Service target pinning for repeatable development environment packages

Direct answer

OBS isolates each build target in a clean build root, but isolation alone does not guarantee repeatable packages. Timestamps, embedded paths, file ordering, and dependency resolution can still change between rebuilds. For long-term repeatability, fix the distribution target and use an immutable repository snapshot instead of a rolling repository. Leap is the safer default because it is a fixed release; Tumbleweed requires explicit snapshot pinning to avoid dependency drift.

Confirmed facts versus likely explanation

Confirmed: OBS build roots are per-target and cleaned before each build. openSUSE Leap is a point-in-time distribution with controlled updates; Tumbleweed is a rolling release whose package versions and metadata change continuously. OBS publish and release actions move packages between repositories, and metadata refresh is not instantaneous, so identical sources can resolve different dependencies across targets or over time.

Likely explanation, marked for review: OBS supports repository snapshots and archive references, but the exact project-metadata syntax and snapshot-ID format vary by OBS version and instance. Do not copy example target paths from unverified sources without checking your OBS documentation.

Steps for this case

1. Choose openSUSE Leap as the OBS target if your team needs stable dependency resolution without managing snapshots. Leap changes only through controlled maintenance updates.
2. If you must use Tumbleweed, pin the build to a specific Tumbleweed repository snapshot in your OBS project configuration. Verify the snapshot reference syntax against your OBS version before committing it.
3. Reference the same snapshot ID in CI pipeline build constraints so developer workstations and CI resolve identical dependency metadata.
4. Avoid floating targets such as unversioned Tumbleweed repositories for repeatable builds.
5. Verify by building the same source twice against the pinned snapshot and comparing the resulting packages with rpm -qpl or diffoscope for differences in file lists, timestamps, and embedded paths.

Missing diagnostic detail

Are you using the public openSUSE OBS instance or a self-hosted OBS, and which OBS version is running? The exact snapshot-pinning syntax and available archive features depend on the instance, and this detail changes the recommended configuration.

Assumptions and uncertainty

• This answer assumes standard OBS project and repository configuration; it does not cover OBS source services or custom build macros.
• Pinning to a snapshot freezes dependencies but also freezes security updates. Plan a separate process to create new snapshots and retest packages when patches are required.
• Repository snapshots are immutable. To apply a patch, create a new snapshot and update the target reference.