I have a similar script to compare two different tags for different Koji instances. The last time i ran it:
% wc -l all3.csv
% grep SAME all3.csv | wc -l
% grep MISSING all3.csv | wc -l
The difference was ~2K packages, where ~1K is actually missing packages in our Fedora/RISCV Koji instance. The rest is older, newer, removed or unknown.
The current status should be way worse.
.X.riscv64 pattern it means there are some changes that are not in upstream Fedora dist-git. If this pattern is detecting scripts avoid rebuilding the package (needs a human to look at it). Some of these changes should go into dist-git as-is, some are temporary hacks that should just go away and probably never see dist-git and some might be too terrible to even consider being part of upstream dist-git as-is.
Because we cannot reuse NVRs we also have
.rvreX (RISC-V rebuild) pattern in
Release: field. This just means the package was rebuilt (i.e. bumped) with no additional changes. This gives us a new NVR.
Our dist-git “overlay” lives here: http://fedora.riscv.rocks:3000/
%check is enabled for the last 2 or 3 years now thus tests are running and passing here.
IIRC (based on Koji reports) we did 7-6K builds (successful ones) a week, but that could be pushed towards 10K builds if you invest yourself a lot.
Jumping from the current F33 to F36 (Rawhide) most likely would be 2 to 4 highly intensive weeks.
I am not really a fan of “total number of package in Fedora”. This number is constantly changing, not all packages are available for all architectures thus total package for riscv64 in Fedora is unknown. For example, valgrind doesn’t support riscv64 and no one is working on that. Which leads to the worst thing: you cannot build 0ad