Modular source rpms not synced when retain-package-versions=1
Version pulp_core == 3.85.1 pulp_rpm == 3.33.0.dev
Describe the bug
When syncing packages using the additive sync policy and retain-package-versions = 1, modular source rpms will not be synced if a "newer" (by simple NEVRA comparison) version is available, even if the newer rpm is from a different module.
To Reproduce
Using the additive sync policy and retain-package-versions = 1, sync a source repo that has modularity enabled and the same package name available in multiple modules.
Expected behavior The newest source rpm from each module should be synced, but we're only seeing the newest source rpm from all of the modules.
Additional context The expected behavior happens for any arch sync (x86_64, aarch64), but fails with the source repos because (at least for any EL distribution I've checked) the source repos don't include modules.yaml. This means the check at https://github.com/pulp/pulp_rpm/blob/2fbd9b7651cc1eaf43e0c87520fa5eb204081e36/pulp_rpm/app/tasks/synchronizing.py#L1281 doesn't work as expected.
I think the sanest way to fix this (though it's a bit of a kludge) would be, in the check above, to see if the release matches the regex .module\+.*\+[0-9]{4}\+[0-9a-f]{8}, and not skip if it does. This could be put behind a flag if necessary.
I'm happy to create a PR if there's agreement that this is the way to go.
Yet another reason to hate modules 🙃
Yeah, I mean, seems like there's not a great solution short of being super conservative and just disabling the feature entirely for source packages.
I don't love the regex idea, but considering modules are on their way out anyway, I'm not against it either. @ggainey wdyt
I don't love the regex idea, but considering modules are on their way out anyway, I'm not against it either. @ggainey wdyt
It is "a bit of a kludge" - esp since release doesn't "have to" have the word "module" in it. But the reality on the ground is that it does - and, everything around the modular/ursine decision is also "a bit of a kludge". As long as we document the hell out of this, I think it's a reasonable way to fix this problem in a non-intrusive way.
Ok, thanks guys! I'll work on a PR for this.