On Tue, 5 May 2020 at 11:35, clime <cl...@fedoraproject.org> wrote: > > 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
If you have any more comments or objections, please tell. I don't know if I got the tone in my previous email completely right. Thanks clime. _______________________________________________ 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
