Rebase migrations in preparation for pulpcore 3.70.

[ggainey]

closes #3828.

[dralley]

@ggainey How should we handle squashing? I'd be OK if we went ahead and did that for the upcoming release, to go alongside pulpcore 3.70

[ggainey]

@ggainey How should we handle squashing? I'd be OK if we went ahead and did that for the upcoming release, to go alongside pulpcore 3.70

Assuming we take the same approach, we'd want to squash migrations up through rpm/3.17 (0001 thru 0040? I think?) the way core does for up to core/3.20, here : https://github.com/pulp/pulpcore/pull/6024/files#diff-b69496c4630640d3ca417ef201dd32986671d2e13dbc6d9e901decb490ff8718

[ggainey]

we'd want to squash migrations

As its own PR, btw - this PR adapts us to the pulpcore changes.

[dralley]

3.17.0 is nearly 3 years old, when we squashed up to pulpcore 3.20, that's actually about 6 months newer than 3.17.

TBH, we have no new migrations since the last major release - which was actually 6 months ago. I'm pretty sure we can squash them entirely (but not delete the existing ones immediately). Plugins are not really the same as Pulpcore, nothing but Pulp RPM depends on Pulp RPM migrations.

[mdellweg]

I realized, after some experimentation, that, if we go for deleting the BaseDistribution as outlined here: pulp/pulpcore#6110 (still a draft proposal, up for discussion), we may need to squash plugins migrations that depend on this model. I'm torn between doing that now while we know what it's all about and postponing that to play safe.

[ggainey]

3.17.0 is nearly 3 years old, when we squashed up to pulpcore 3.20, that's actually about 6 months newer than 3.17.

I think we're saying the same thing? I'm contending that we'd squash up through 3.17, because rpm/3.18-core/3.21 are used together by several downstreams, so rpm/3.17 is the "newest rpm used with core/3.20 or earlier".

I'd just like to see this PR be only "adapt to the pulpcore squash", and have a separate, later, PR, be "squash rpm up thru 3.17". Does that make sense?

[dralley]

My thought was always that we would squash plugin migrations before doing so for pulpcore. It simplifies everything quite a bit because at that point you know that nothing depends on those migrations (except for a 3rd party plugin I guess)