Issue #5706: base_version can cause content to show as added, even though it was in the previous version - Pulp

Actions

Send by e-mail Copy link

Issue #5706

closed

base_version can cause content to show as added, even though it was in the previous version

Added by bmbouter about 5 years ago. Updated almost 5 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

fao89

Category:

Sprint/Milestone:

3.0.1

Start date:

Due date:

Estimated time:

Severity:

2. Medium

Version:

Platform Release:

OS:

Triaged:

Yes

Groomed:

Sprint Candidate:

Tags:

Sprint:

Sprint 63

Quarter:

Description

This was originally reported on IRC by gmbnomis.

Reproducer¶

1. Create empty RepositoryVersion, version 1.
2. Create a second RepositoryVersion by adding content unit B
3. Create a third RepositoryVersion, by adding content unit A AND use version 1 as the base_version

Issue¶

Observe that for RepositoryVersion 3, the added field shows A & B to be considered added, even though B was already present in RepositoryVersion 2.

Actions

Copy link

Updated by bmbouter about 5 years ago

Description updated (diff)

Actions

Copy link

Updated by gmbnomis about 5 years ago

bmbouter wrote:

This was originally reported on IRC by gmbnomis.

I got this one wrong and probably created lots of confusion. The reproducer is the same, but what I meant to say is:

Issue¶

Observe that for RepositoryVersion 3, the added field shows A to be considered added, and B as removed.

This is consistent with how the added and removed sets are defined (they show additions/removals with respect to the previous "latest" version (i.e. /2/ in this case)).

However, when a repo version finalizer looks at a repo version changes, it is interested in changes relative to the base version.

For example, assume we use a finalizer that removes dependent content for a removed content unit. Suppose that A depends on B. If the finalizer looks at the .removed set (containing B), the finalizer will remove A, which does not make sense.

Thus finalizers need other change sets than .added and .deleted. Currently, RepositoryVersion does not offer such sets comparing two (arbitrary) repo versions.

Actions

Copy link

Updated by daviddavis about 5 years ago

Tracker changed from Issue to Task
% Done set to 0

Actions

Copy link

Updated by daviddavis about 5 years ago

Tracker changed from Task to Issue
Severity set to 2. Medium
Triaged set to No

Actions

Copy link

Updated by fao89 about 5 years ago

Triaged changed from No to Yes
Sprint set to Sprint 62

Actions

Copy link

Updated by rchan almost 5 years ago

Sprint changed from Sprint 62 to Sprint 63

Actions

Copy link

Updated by daviddavis almost 5 years ago

Currently in RPM, we get the base (or last) version and find the content that has been added and removed. It's not a good solution but it's a workaround now at least.

My initial feeling is that added() and removed() should stay the same (given that 3.0 has released). But maybe we can either add an optional argument to alter their behavior or maybe we should introduce a new set of methods?

Actions

Copy link

Updated by fao89 almost 5 years ago

I would go with an optional kwarg,
keeping added and removed as is for the default behavior, and changing it when kwarg is passed

Actions

Copy link

Updated by ipanova@redhat.com almost 5 years ago

One of the possible solutions would be to check for the optional kwarg which would be the base_version and if present then take that version instead of 'latest' version.

Actions

Copy link

#10