`apt` lock can contain multiple package versions for one architecture

[hartikainen]

Hey folks,

I think the apt module extension can add multiple versions of the same Debian package for one target architecture when separate root dependency closures resolve that package from different suites.

I expected a generated lock to contain at most one package for each (Package, target architecture) pair. Instead, in my use case, I observe both of these records:

/noble-updates/libssl3t64:amd64=3.0.13-0ubuntu3.9
/noble/libssl3t64:amd64=3.0.13-0ubuntu3

The updated entry came through openssl, while the older entry came through librabbitmq4. The latter only requires libssl3t64 (>= 3.0.0), so the updated package satisfies both dependency closures. Including both .deb archives can make the resulting filesystem depend on archive order because they install overlapping paths.

My Setup

• Rules Distroless 0.9.4
• Bazel 9.2.0
• Ubuntu Noble
• Architectures including amd64

Reproduction

A lockfile unit test can reproduce this without downloading package indices:

1. Add libssl3t64 version 3.0.13-0ubuntu3.9 from noble-updates.
2. Add libssl3t64 version 3.0.13-0ubuntu3 from noble.
3. Add librabbitmq4 and an edge to the older libssl3t64.
4. Inspect the resulting package records and dependency edge.

The lock currently contains all three records, and librabbitmq4 points to the older noble key. I expected the lock to contain two records and for the edge to reuse the already-selected noble-updates package.

This appears related to, but distinct from, #184 and #189. If I understand correctly, those address duplicate dependency entries within one package. In my case, the lock contains two complete package records with the same Debian package name and target architecture. #137 prevents multiple versions within one resolver traversal, but separate root closures are still resolved and combined.

Possible fix

I created a reproducer and a fix (both with help from Opus) in two separate commits available at 47042ff and 3250470. The fix keeps the serialized package keys unchanged, but maintains an in-memory index keyed by (Package, target architecture) while constructing the lock.