Hey Florian, On Mon, 4 May 2020 at 10:03, Florian Weimer <fwei...@redhat.com> wrote: > > > as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags > > pushed by package maintainers) effort, I revisited the sorting > > algorithm that is used to determine the "latest" tag for a given > > package which is needed to determine correct package version. > > Basically, if the current commit is tagged, then the N-V-R information > > from that tag name is directly used to render version or release > > (depending on macro usage). If the latest tag is on some older commit, > > we still use information from it but the version (or release) string > > will contain some appendices like .git.4.abcdef12 to mark a commit > > offset from that latest tag. Note that only tags accessible from the > > current branch tip when traversing git history backward are considered > > to pick the latest one (i.e. tags on other separate branches are not > > considered). > > Is this really necessary? Koji goes by latest tagged build, it does not > sort by NVR when constructing the buildroot. The same thing seems to > apply to composes (but I am less sure about that).
is it certain? I tried to poke around koji/kojira code, kojí IRC, and also logs at: https://koji.fedoraproject.org/koji/tasks which are very slow for owner:kojira, state:all but I couldn't really determine so far whether only the latest build of a package gets to "build" repository (that is used for builds subsequently) for a given tag. My (maybe wrong) understanding would be that all packages tagged into a certain tag (let's say f33) are included in the resulting "build" repository. Afterwards, dnf is used to create the actual buildroot for the package being built and dnf does (E-)N-V-R sort so it filters out any older package versions. If you build a package with an older version than what was there for previous build, does that older version overrides the newer one? I would need to poke more to find out. But it would be very interesting to know. > > So I don't see why you would need any sort of NVR sorting. Basically, > you can go back through the history and use the first tag you encounter > as the baseline. Tags also need to be sorted to render changelog records from their bodies in the correct order. What you suggest is the topological sort but it does not resolve the case when multiple tags are attached to the same commit. I would like to have the ordering defined for this scenario as well just in case. > > However, I think this whole approach is a bit fishy. Tags should be > pushed by Koji once a build completes, so that it is easy to identify > matching sources reliably, not by the packager. Well, it's true that with this approach you could make sure that the tags for the built packages are present after each build. That gives you a quick way to jump to a specific source code point based on a package name. With my suggested approach, pushing the tags would be an optional thing so it would only work for packages which do that. On the other hand, the build-induced tags are simply marks. They can't be used as a primary source for either changelog or release information. They do not need to be annotated, just simple tags. They can live a separate namespace which is what rpmautospec gentlemanly does at the moment. > Tags can also be added > retroactively and backdated. These things conflict with the advantages > you list (in particular, with NVR auto-generation, git is not the sole > source of truth). If the tag ordering function is done properly, I believe even retroactive tagging (i.e. tagging into past) and/or tag backdating would be supported and NVR auto-generation would work correctly. So I don't think it needs to conflict. But can you perhaps expand more on "Tags can also be added retroactively and backdated", please? I.e. why/when would one do that. Today, git is the sole source of truth for NVR information and changelog with the exception of %{dist}, which in most cases is pretty much equivalent to dist-git branch name. So, the annotated-tags proposal is such that it keeps git the source of truth for NVR and changelog but to avoid conflicts between branches and to allow for making those information dynamic, it moves that information from spec files out to git metadata. Thank you clime > > Thanks, > Florian
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
