On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote: > Hello! > > What is the point of including number of builds into release? I think > the Miro's approach solves it. > Or is there any other problem except soname bumps? It makes it easier to do rebuilds which means it makes it easier and simpler to do mass-rebuilds. > Ad. document - annotated git tags: > (-) Editing the changelog would mean allowing to remove the git tags, > thus leading to potential issue in build reproducibility > > That doesn't need to be the case. In rpkg-util, this was resolved by > introducing arguments since_tag and until_tag > for git_changelog macro > (https://docs.pagure.org/rpkg-util/macro_reference.html#git-macros). > That's > how it can be prevented for some annotated tag to contribute to changelog. > > Example: > > {{{ git_changelog since_tag=name-1.3-1 }}} > > * Mon Feb 24 2020 clime <clime@xxxxxxxxxxxxxxxxx> 1.2-1 > - manual changelog entry that is used instead of a tag annotation > > {{{ git_changelog until_tag=name-1.1-1 }}} Interesting idea. > Removing already pushed git tags is probably not a good idea anyway: > https://git-scm.com/docs/git-tag#_on_re_tagging We very much agree that removing git tags is not a good idea, that's why we listed it as a con :) > Ad. the following approach for calculating release: > - Compute the release field from the number of commits since the last > version change: <version>-<commits_number>%{dist} > > I think it is a good idea. In rpkg-util, it is done similarly, except > the release part has more subparts than just > two (including %{dist}). If you make the build system provide the ${dirty_appendix} and drop the ${pivot} (because we want to generate the release, so there is no input specified), you get very close to what we described. > The full description is here: > https://pagure.io/rpkg-util/blob/master/f/man/rpkg_man_page.py#_262 > but the main difference is that it counts commits from the latest > annotated tag which contains (in its name) > the current version and the current release number which are extracted > from the spec file when > creating the tag unless they are specified manually on command line. > Commit count is only appended > to it if we build from commit which is on top of some annotated tag > (i.e. it is itself untagged). > > Going by just a textual version change in a spec file might be slightly tricky. > You would need to go through all the past commits that touched that spec file, > keep checking these out and look if the version is changed when compared to the > one parsed from the head commit. Possible though. This is basically what I had in mind. > To go back to your original post: > > For both the release and the changelog fields we believe using RPM macros would > > satisfy the requirements we have for opting-in/out: > > By using such RPM macros, you would lose ability to rebuild srpms > because it will > be only possible to build them when the git context is present but not when they > become a standalone thing. I.e. things like this will not work: > > https://github.com/rpm-software-management/mock/blob/cfe34c8a57/mock/py/mockbuild/backend.py#L270 > > That's why I think that such macros should be of a different kind: > macros that are computed > once when srpm is created and result of which is put _verbatim_ into > the spec file so that > there is no (re)computation later when srpm is being built and when > the git context is already > missing. We had a discussion with Neal about this topic on #fedora-apps yesterday and I believe one of the outcome of this discussion was that we should indeed use this approach, for the reasons you're mentioning. Thanks for your feedbacks and thoughts (and links!) Pierre _______________________________________________ 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
