Learn more about these different git repos.
Other Git URLs
<class 'psycopg2.IntegrityError'>: duplicate key value violates unique constraint "rpminfo_unique_nvra" DETAIL: Key (name, version, release, arch, external_repo_id)=(texlive-metre, svn18489.1.0, 2.fc29, noarch, 0) already exists.
Now, it is true, texlive-metre (a subpackage of texlive) did have a previous build from texlive-2017-2.fc29 that had nvr of svn18489.1.0, 2.fc29. The missing fact is epoch. In that old build, epoch was 7, now it is 8.
Whatever check is happening here is not factoring in epoch, and needs to.
epoch has never been part of the uniqueness condition. It's tremendously confusing to have duplicate nvrs/nvras, regardless of epoch.
Is this really a problem?
For texlive, it definitely is, but I am able to hack around it by artificially inflating the Release value.
Metadata Update from @mikem: - Issue tagged with: discussion
I'm pretty hesitant to change this condition. It's baked in fairly deep and it's been that way since day one. RPM filenames do not contain the epoch, and many interfaces display nvr rather than e:nvr.
Why are we using epoch instead of release to distinguish? Changing the release value for a new build hardly seems artificial to me.
In texlive (a horrible package to be fair), each subpackage has a different version, many of which do not change at all for long times (including "never"). The base texlive release happens once a year or so (2017XXXX to 2018XXXX). We need to force Fedora users to update these subpackages to reflect the change in the texlive ecosystem, so we have been using Epoch (also because it is plausible that version ordering is not sane). When I change the master version, I had been resetting release back to 1. We can just never reset the release value back to 1 in the future to work around this problem.
Login to comment on this ticket.