Hello,
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).
Originally, I sorted tags to find the "latest one" by using git directly and the criterion was -taggerdate which means the latest created tag by time goes first.
I realized this will mess up the ordering in case a packager would create a tag into the past (i.e. on some older commit). That tag, while belonging to an older commit and probably having an older NVR, would be selected as the latest tag.
I am not sure how much this is a practical problem but I don't think people would expect this so I started to look for some perhaps better sorting algorithm.
One idea was to employ a topological sort, i.e. sort tags as they are encountered by traversing current branch tip backward in Git history. This would solve the above problem with tagging past commits but when there are multiple tags on the same commit another criterion and probably time-based one would be needed to determine order between those. In addition, pure topological sort of tags is kind of clumsy to do from the Git command-line.
So I decided to to use git for-each-ref --sort='-taggerdate' --sort='-*committerdate' - i.e. use date of tagged commit as the primary criterion and creation of tag as the secondary criterion. This emulates topological sort given that people have the correct time set on their machines. Regrettably, there is a bug in git (which was very quickly fixed https://public-inbox.org/git/CAGqZTUvaiDQbiQ1dOoqLcy+GHZg+BuXY=Z+S=Dpsq=wm44...) that causes -taggerdate not to be taken into account.
I was able to work-around it by using git for-each-ref --format to print the relevant timestamps and then use sort command-line utility to sort the tags. The problem with this is that it has "only" 1-second resolution and therefore the order of tags created within one second is indeterminate. It's therefore not 100% predictable. And also it is time-based, so if someone has a wrong time set on his/her machine, it might not work.
So finally, I started to think about sorting the tags by RPM sort. Their names have N-V-R format so it kind of makes sense to use rpm to sort them. You could tag into past and that tag will be considered the latest one only if it has the highest N-V-R.
What do you think? What is the best sorting approach here?
Thanks clime
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).
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.
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. 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).
Thanks, Florian
Hey Florian,
On Mon, 4 May 2020 at 10:03, Florian Weimer fweimer@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
On Tue, 5 May 2020 at 11:35, clime clime@fedoraproject.org wrote:
Hey Florian,
On Mon, 4 May 2020 at 10:03, Florian Weimer fweimer@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.
Hey Florian,
On Mon, 4 May 2020 at 10:03, Florian Weimer fweimer@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.
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
On Tue, 5 May 2020 at 18:46, Florian Weimer fweimer@redhat.com wrote:
Hey Florian,
On Mon, 4 May 2020 at 10:03, Florian Weimer fweimer@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.
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.
Good to know. But hard to say now how much inspiration can be really drawn from this.
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.
It really depends on what the tag ordering function is. If the function does not consider dates at all, this wouldn't be a problem.
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*.)
What do you mean by "everything else which can get out of sync and change"? If you are talking about tags (or refs in general), it's true that you can add tags into past which may or may not affect auto-generation depending on the ordering function. You could potentially also remove some tags if you haven't distribute them yet. But you should never push a tag with the same name that you have pushed before (https://git-scm.com/docs/git-tag#_on_re_tagging) - that makes the removal mentioned in the previous point kind of something which should perhaps be forbidden as well.
So given this: 1) if we order tags by time of their creation, then if you create a new tag on the past commit, that tag will be considered the latest for the tagged commit itself and all the commits "above it" (i.e. commits further in git history) even if those commits have other tags (with older creation dates) assigned to them. These won't be used for auto-generation and instead the new intruder will be. If you try to build from some commit further in history now (e.g. by specifying an older tag for that commit which will lead to its checkout in the build system or just commit ID directly), the package N-V-Rs you start to get will look e.g. something like this: foo-1.0-3.git.8.abcdef12. foo-1.0-3 was the most recently created tag and we get the respective .git. suffix because the commit we want to build will be 8 commits past that latest tag and will have a hash starting with abcdef12. 2) if we order tags primarily by tagged-commit creation date and secondarily by tag creation date, then tags into past do not play any role given that there is some other tag placed on a later commit. Again, I am assuming we are in a detached-head state where we have just checked out some commit ID or a tag-name, which should now be built. So if there is that "later tagged commit" between our current detached head and the new, into-the-past created tag, auto-generation won't be affected. If, however, there isn't such later tagged commit, it means that we will get a different N-V-R than before when we built from that same commit. That new N-V-R will contain the newly created tag and might contain the .git.<n>.<hash> suffix appended to it if the checked out commit is later in history than the commit for the past-tag. 3) if we order tags not by time but their placement in git history topology, there is a problem that this doesn't give us a sorting criterion for tags which are at the same distance from the current HEAD. So we need to apply another criterion to resolve this, e.g. again tag-creation date or alphabetical sort. If we do this, we get basically the same result as for 2). Tags into past only affect anything if there is no later tag between HEAD and that newly created past tag. Now "later tag" is being primarily determined by topology instead of commit date. These two are equivalent given that people have correct time set on their machines. 4) if we order tags by rpm sort on N-V-R tag names, tags into past play a role if they suddenly become the latest ones with respect to the current HEAD being built. "Latest ones" according to rpm sort and they need to be reachable from HEAD to be included into the sort in the first place.
I am not sure whether I am not over-complicating things now. I.e. how much tagging into past is a real use-case and when it would be useful.
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).
I don't think you can automatically generate %changelog and Release and at the same time base their auto-generation on their last change in spec file in git history. That somehow doesn't seem that it would work.
There were suggestions to do the auto-generation based on the last Version change. That would have the property that when you build from the same commit again and again, you will get the same N-V-R and changelog no matter what happens later in time.
That's a nice property but I am not sure it is something we necessarily need. With tags it may happen that you get a different N-V-R or changelog if someone created a new tag into-the-past but it won't happen that you get the same N-V-R that you have got at some other point in time. I.e. N-V-Rs are unique even though they may change in time for the same commit.
Tagging into past is imho rather a theoretical use-case but useful to consider.
Thanks, Florian
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.
It really depends on what the tag ordering function is. If the function does not consider dates at all, this wouldn't be a problem.
The commit graph is ordered, but everything else is not. Tags (whether annotated or not) are outside the commit graph, so their order is not fixed.
I think this is different with Mercurial, where tags are part of the commit graph.
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*.)
What do you mean by "everything else which can get out of sync and change"? If you are talking about tags (or refs in general), it's true that you can add tags into past which may or may not affect auto-generation depending on the ordering function.
What kind of ordering function could tell apart a retroactively added tag and one that was there when the build was submitted?
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).
I don't think you can automatically generate %changelog and Release and at the same time base their auto-generation on their last change in spec file in git history. That somehow doesn't seem that it would work.
I don't know of any problems, and I have implemented this in the past (although in a very different context).
Tagging into past is imho rather a theoretical use-case but useful to consider.
Is it? It can easily happen if you forget to push a tag and then do a build, and push it later.
Thanks, Florian
On Wed, 6 May 2020 at 11:00, Florian Weimer fweimer@redhat.com wrote:
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.
It really depends on what the tag ordering function is. If the function does not consider dates at all, this wouldn't be a problem.
The commit graph is ordered, but everything else is not. Tags (whether annotated or not) are outside the commit graph, so their order is not fixed.
Well, the assumption is that the order of tags will become fixed by our tooling, i.e. that we will supply the ordering.
I think this is different with Mercurial, where tags are part of the commit graph.
Interesting, I will look into it.
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*.)
What do you mean by "everything else which can get out of sync and change"? If you are talking about tags (or refs in general), it's true that you can add tags into past which may or may not affect auto-generation depending on the ordering function.
What kind of ordering function could tell apart a retroactively added tag and one that was there when the build was submitted?
Generally speaking, yes, N-V-R and changelog will be affected by adding a tag retroactively. I.e. you build some commit, you add some tag, you build the same commit again => NVR and changelog can now be different.
What can be done here, is that when we build from a tag, build system will pass that tag name (or tag object ID) to the tooling through environment so the tooling will use that provided tag as the "latest one" instead of identifying it through sort. I.e. if you build from a tag, you will always get the same N-V-R over and over again, no matter what happens in time. You can get a different changelog, however, if someone tags some older commit by an older version, i.e. my current version of software is foo-1.1-3 but someone wants me to do an official release/build of an older version for some reason, so i'll tag an old commit with e.g. foo-1.0-2 and the changelog record for foo-1.0-2 will now additionally appear in all new builds.
But I personally think that N-V-R uniqueness is a more important property than N-V-R sameness when you build the same commit across time repeteadly. N-V-R sameness for tagged commits can be implemented by adding a special handling of tag/release builds as opposed to testing commit builds for which N-V-R sameness won't hold. Changelog sameness can't also be assured (at least not easily) but it may or might not be an issue.
By N-V-R uniqueness I mean that you can't get the same N-V-R for two builds of two different commits.
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).
I don't think you can automatically generate %changelog and Release and at the same time base their auto-generation on their last change in spec file in git history. That somehow doesn't seem that it would work.
I don't know of any problems, and I have implemented this in the past (although in a very different context).
I would need and like to see the implementation so that I understand what you meant exactly.
Tagging into past is imho rather a theoretical use-case but useful to consider.
Is it? It can easily happen if you forget to push a tag and then do a build, and push it later.
Well, if you don't push the tag and you do a build, you will get N-V-R like foo-1.0-1.git.3.abcdef12. E.g. it won't be a clean N-V-R because it doesn't come from a tagged commit. If you push a tag and repeat a build from that same commit (or from that tag, see above), you will now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{ git_dir_release }}} is used in the spec file to enable the automatic generation of release. The annotated tags represent releases. if you build an unreleased commit, you get a "work-in-progress" N-V-R and also changelog won't be populated with the latest changes. This workflow needs "pushing a tag" to be a build trigger so that it is convenient.
Best regards clime
Thanks, Florian
<snip>
Well, if you don't push the tag and you do a build, you will get N-V-R like foo-1.0-1.git.3.abcdef12. E.g. it won't be a clean N-V-R because
I meant "I.e." there, not "E.g."...just to be clear.
it doesn't come from a tagged commit. If you push a tag and repeat a build from that same commit (or from that tag, see above), you will now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{ git_dir_release }}} is used in the spec file to enable the automatic generation of release. The annotated tags represent releases. if you build an unreleased commit, you get a "work-in-progress" N-V-R and also changelog won't be populated with the latest changes. This workflow needs "pushing a tag" to be a build trigger so that it is convenient.
Best regards clime
Thanks, Florian
On Tue, May 05, 2020 at 06:46:48PM +0200, Florian Weimer wrote: ...snip...
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.
koji operates on source packages, so as long as the source packages are differently nameed, both subpackages would be there. What happens next depends I think on what tool takes those packages and does things with them. If they weere exactly the same, mergerepos_c would likely error and the buildroot might be broken. Pungi might exit or might just pick one. :)
kevin
On Thu, 7 May 2020 at 20:50, Kevin Fenzi kevin@scrye.com wrote:
On Tue, May 05, 2020 at 06:46:48PM +0200, Florian Weimer wrote: ...snip...
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.
koji operates on source packages, so as long as the source packages are differently nameed, both subpackages would be there. What happens next depends I think on what tool takes those packages and does things with them. If they weere exactly the same, mergerepos_c would likely error and the buildroot might be broken. Pungi might exit or might just pick one. :)
After some additional discussions git IRC, git mailing list, rpm-ecosystem IRC, and also taking into account how Koji works and what Florian was saying, I so far concluded that the sorting should be:
1) topological as a primary criterion 2) NVR-based where the "topological" criterion is not enough (multiple tags on the same commit, or when there are multiple "parallel" tags on merged-in branches)
Doing just NVR rpm sort would work as well as long as people don't accidentally push some tag which would sort above even all future tags. Doing 1) as a primary criterion has an advantage that you can recover from this situation on your own even without deleting the remote tag (by pushing a new even empty commit and tagging it correctly this time :)).
So doing 1+2 is more resilient against errors. libgit2-devel + rpm-devel were suggested to me so I'll try that to implement the tag sorter :).
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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