Story #4295
Updated by ttereshc almost 6 years ago
h3. Motivation Currently it is possible to have multiple UpdateRecord content units (previously known as "errata") with the same @id@ in one repo version. Those content units are not full duplicates, they have the same @id@ but different content. That leads to a creation of a bad repository at a publication time (@id@ of an update should be unique per yum repo, so Pulp needs to publish only one update per @id@). h3. Possible cases At sync time in additive mode: # Repo version 1 contains an updateA, in repo version 2 a newer version of the updateA is being added # Repo version 1 contains an updateA, in repo version 2 an older version of the updateA is being added # Repo version 1 contains an updateA, in repo version 2 an alternative version of the updateA (e.g. for different distribution) is being added In case of a mirror mode, always the incoming version of the updateA is taken, regardless of the `updated_date`. taken. h3. Suggested solution Each repo version should have no more than one UpdateRecord with the same @id@. Decide which update to keep based on the `updated_date` `updated` timestamp (it's already among required fields on the model). Technical proposal: - before RemoveDuplicates stage, allow a declarative content unit to go to the RemoveDuplicates stage if it's the one which should stay in a new repo version, remove it from the output queue otherwise. - add RemoveDuplicates stage which would remove duplicated UpdateRecord by @id@. Expected result: - case1 - newer version of the updateA is in the repo version 2 - case2 - no changes in repo version 2 with regards to the updateA - case3 - result is based purely on the `updated` timestamp, no other logic is involved, the alternative version of the updateA will be in repo version 2 if its timestamp is newer. NOTE: this case is probably not very common but still worrying if we mutate the updateA silently. We can add logging for any mutation of an update but it will cover not only case3 but case1 as well.
.