The latest builds in a given koji tag are the ones that are most recently tagged. When there is inheritance, then the highest in the inheritance takes priority. So:

• any builds directly in the tag take precedence over inherited ones
• if you tag a build, it becomes latest in that tag, regardless of NVR

Koji never performs an NVR comparison for this. The relevant tag_listing queries are ordered by create_event descending.

How can I modify it so that when I dist-repo, it can release the newest builds.

There is no option for Koji to sort builds any other way. If you want the highest NVR to be latest, then you need to make sure it is tagged most recently.

Note that NVR sorting is not an entirely well defined algorithm and the rpmlib implementation has changed over time.

This is really more of a question than an issue.

Your answer helps, and where to ask a question about koji?

IRC: #koji on libera.chat or mailing list koji-devel AT lists.fedorahosted.org

I got bitten by this lately. I staged builds for some time in a tag, then moved all the builds another tag when I deemed all of it ready. It did not occur one second to me that I had to order the tagging, which I did in a single koji move command with all the builds contained in the tag:

export FROM=v8.3-testing; export TO=v8.3-base; koji list-tagged $FROM --quiet | cut -d ' ' -f 1 | xargs echo koji move $FROM $TO

So now for some packages the latest builds are not those with the highest NVR, which makes the exported yum repositories (during the development phase, I export all builds, not just the latest) inconsistent with what koji actually uses internally to produce the next builds. Thankfully there was a build breakage due to this which made me realize this, otherwise I would have kept building things with obsolete build deps.

In addition to this I occasionnally produce new builds with a lower NVR than the latest in a tag, thinking that the highest NVR wins when it actually doesn't :/

I guess there are reasons behind this behaviour, but it can definitely cause issues in some workflows and needs extra care to be given to how we tag builds.

May I suggest this fact be documented in the docs and in the output of koji clients (CLI, web) anytime the "latest" builds are mentioned to avoid such confusion?

Oh, another question: is this tagging order koji actually uses to determine what the latest build is actually visible somewhere? My koji instance isn't running on the latest code so maybe there is, but I couldn't find such information either in the web interface or in the output of CLI commands just as list-tagged.

Few notes:
- koji clone-tag is what you want instead of koji move-build. While first one persists all tagging order, etc, second one is move a "copy"
- koji list-history --tag <tag> --active would give you more info about tagging order. brew list-tagged <tag> <package> gives you outpout also in correct order. (or options like --latest or latest-n=3.

In fact this ordering is used everywhere.E.g. koji latest-build --help points to https://docs.pagure.org/koji/HOWTO/#package-organization - but maybe it is not that explicilty written there.

Thanks for the insight. I never used clone-tag, but is it really appropriate when the src and dest tags already exist?

How would you use it, knowing that src tag inherits dest tag? koji clone-tag src dest --builds --no-delete (and possibly --latest-only if you don't want to propagate the build history to the dest tag) ? Do you then need to untag the builds from the src tag?

Hmm, not sure how your workflow really looks. But it shouldn't be dangerous.
- for existing dst tag - normal workflow is that you've some "snapshot" tag which you update from src tag. So, it is a bit problematic if there are some other builds/packages which are not present in src. If --no-delete is used, builds are ordered in dst by time (or to be precise "event") of tagging. So, it would be interleaved depending on these events.
- Inheritance shouldn't be an issue. It firstly takes a current list+history from src tag (depending on --inherit-builds), then the same from dest tag and order the things and update the dest tag. So builds propagated from dst and not overriden by "newer" builds in dst will not be touched.
- For untagging - yes, it is read-only operation on src tag.
- Anyway, I would suggest to play first with some testing tags to get better understanding what is happening there. You can easily break something this way.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3826

Please continue any further discussion there.