> Hey Florian, > > On Mon, 4 May 2020 at 10:03, Florian Weimer <fweimer@xxxxxxxxxx> 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. The latest tag for a source package name wins for the Koji-generatged repository. I don't know what happens if different source packages build subpackages of the same name. > 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. Yes, if it gets tagged into the buildroot, it replaces a build with a higher NVR. >> 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. No, you can push tags with incorrect dates. This can change the auto-generation. You can only avoid this if you use data from commits (both current and earlier) *on the same branch* exclusively for generating metadata (or hash-linked from there). Everything else can get of sync and change over time even if the commit hash stays the same, so the repository state at a specific commit hash is longer the sole source of truth. (Because you need to reconstruct that other state *at the right time*.) That's why I proposed to auto-generate release numbers and changelogs based on the commits going back to the last Release: line and %changelog section update in the spec file. That would be stable (unless the tool changes how it generates those spec file parts). Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
