Bug 1702771

The legacy createrepo (not to be confused with createrepo_c) has been deprecated and is already gone from Rawhide:
https://src.fedoraproject.org/rpms/createrepo/c/0cd7846754c5179a41bfdc4fdd61cfa440af8122?branch=master

That said, there's no point in rebuilding it for F30 at this point.  Please use createrepo_c instead ("dnf install createrepo" picks that one by default as well).

To fix this the Fedora 28 RPM _needs_to_be_removed_ from the Fedora 29 and Fedora 30 packages. 

I provided links to the 29 & 30 packages, and I can clearly see that the Fedora 28 package for createrepo is still there.

This cannot be fixed in the way proposed. The release repositories are frozen, they are not modified by policy. What is in them, is in them for all time. Note, there is an assumption here that an F28-versioned package being in an F29 repo is a bug: it is not, this happens all the time, for packages that fail mass rebuild or aren't included in the mass rebuild. *In itself* there is nothing wrong with this; there is nothing inherently wrong with the 'createrepo' package in F29 being one from the F28 era, if that package works OK. There never was a successful F29 or F30-era build of createrepo, but this in itself is not really a problem exactly.

If there's a real problem here, it's that the migration from createrepo to createrepo_c has been somewhat muffed in F29 and F30.

The frozen F29 and F30 release repos contain createrepo_c packages that Obsoletes: and Provides: createrepo. Later on, Pavla Kratochvilova decided that createrepo_c obsoleting createrepo was a mistake for these releases and sent out updates that remove the Obsoletes and Provides for releases earlier than F31, but this did not have the effect that Pavla thought it would. Because the older createrepo_c that obsoletes createrepo is *still in* the frozen release repo, when you upgrade from an older release to F29 or F30 currently, createrepo is still replaced by createrepo_c - just by the older version in the frozen repo, rather than the newer version in the updates repo. On the next system update, the old version will be updated to the version from the updates repo. (Note, this is why createrepo_c updates for F29 and F30 always fail a couple of openQA tests.)

I'd suggest that, as we can never take the createrepo_c packages with Obsoletes: and Provides: out of the frozen release repos anyway, the Obsoletes: and Provides: should be restored to current F29 and F30 builds of createrepo_c, so this weird two-stage thing doesn't occur (and the openQA tests pass). The other way to make things 'consistent' here would be to do a fake 0.11.0-versioned build of the old 'createrepo' for F29 and F30; as the Obsoletes are versioned "< 0.11.0", this would make them no longer take effect, and make 'createrepo' a current package for both releases again.

Fixed upstream:
https://github.com/rpm-software-management/createrepo_c/pull/162

Note that I have "hijacked" this BZ to fix the broken migration path described by Adam above.  The original issue reported in this BZ is already considered fixed.

FEDORA-2019-4448e01a41 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4448e01a41

createrepo_c-0.14.2-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4448e01a41

createrepo_c-0.14.2-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.