ReleaseComponent content with different codename or suite but equal distribution collides

[quba42]

Workarounds for DuplicateDistributionException

If you are getting an error message as follows:

Cannot create the new repository version, since it contains multiple Release content with the same distribution '<distribution>'.
This known issue is tracked here: https://github.com/pulp/pulp_deb/issues/599
You can check the issue for known workarounds. Please also consider posting what you did before getting this error, to help us to fix the underlying problem more quickly.

Then you have hit our error (DuplicateDistributionException) for this issue.

• If you have hit it while syncing, you might be able to work around the problem by using the sync option mirror=True on your next sync attempt.
• Alternatively, you can sync the affected remote into a new empty repository, since this error cannot occur on a first time sync into an empty Pulp repository.

Please also consider posting below, to describe exactly what you did, before getting the above error.

Problem Description

We noticed this while working on the advanced copy mode, which currently works as follows: If a user copies packages from one repo version to another, the advanced copy will find any PackageReleaseComponents that reference those packages, as well as any associated Components, and Releases, and move them along with the packages to preserve structure. However, this can result in multiple Releases with the same distribution (differing only in their codename or suite) within the same repository version. This will collide during publication since the APT publisher will try to create the path to the duplicate distribution twice.

There are several conceivable ways to address this issue:

The clean design

• Structure content should contain exclusively structure information. Therefore we remove the codename and suite fields from the Release model (and probably rename that model Distribution while we are at it). Collisions are now no longer possible and structure content is equally valid (to describe structure), regardless what repo or repo version it is in.

Pros: This is clearly the conceptually cleanest possible design.

Cons: This would require a massive DB migration to merge existing colliding structured content (and then to regenerate all the associated ReleaseComponents and PackageReleaseComponents for all existing repo versions!

Embracing our existing (bad) design

• Structure content only makes sense within some given RepositoryVersion. It can never be moved anywhere else. The advanced copy needs to be redesigned to create new structured content in the target version, rather than taking along structured content from the source version.

Pros: No massive DB migration.

Cons: We will remain limited by our early design choices for ever, whatever the consequences.

For completeness sake (the complete mess)

The APT publisher needs to learn to accept that there can be multiple distributions in a single repo version and just publish them anyway.

Cons: Creating the distribution path might be simple to make duplicate safe, but what about merging the colliding package indices. This approach strikes me as a non-starter: an ever escalating mess of corner cases.

[daviddavis]

We're dealing with a similar problem: how to reference repo's releases. Since distribution is not unique across a repo's releases, we can't reference a repo's release with the repo href and release distribution.

Maybe this is implied in the first design but I suggest setting repo_key_fields = ('distribution', ) on the Release model similar to how NVA are defined on Package`. This should prevent two releases with the same distribution from being added to a repo.

[quba42]

repo_key_fields = ('distribution', ) would be a very good initial solution. It is literally a one liner to implement, and it will prevent users from building broken RepositoryVersions that cannot be published (through no fault of their own).

Then I can take all the time in the world to decide if I really want to go the route of completely redesigning the way the Release content works (with the horrendous DB migration that would entail)...