Hey pingou! On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > 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. ${dirty_appendix} is a part intended for development purposes, i.e. to be able to have versioned working tree when working locally without committing. It will be empty if working tree is clean, which should always be the case in a build system (there is more info here https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_9 on this). I am guessing you think about number-of-builds as the ${dirty_appendix} ? That would need to be a normal rpm macro provided by a build system (similarly to %dist). Anyway, if the number-of-builds part is just to optimize mass rebuild process, I would try to look if we can tweak the build system to be able to do the mass rebuilds without making new commits back to dist-git and even without that %number-of-builds macro. In my opinion, it should be possible. There is already BUILDTIME in rpm headers that can be used to differentiate between newer and older rpm with otherwise the same nevr. In rpkg-util, ${pivot} (the main release number) is generated automatically (when the git_release macro is employed) but packager can also hard-set it at any time to any value. I think with the pivot number, the upgrade-path problem would be solved cause the commit-count appendix is only used as delta since the last pivot change, which is marked by an annotated tag in the git tree. So the commit (having an annotated tag on it) in older and newer Fedora release (branch) would generate an rpm with the same NVR and just the %dist decides then (there can also be two separate tags if %dist is used in the Release string and if it is configured not to be empty as i do it now rpkg-util :) but this is another discussion). The pivot is also useful for post/pre-releases and other cases described here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning It is then useful to have something that can be configured by hand. > > > 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. Yes, it takes slightly more computational time than being navigated by tags themselves that can be used for version bumps as well as release bumps. > > > 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!) Right, I will be very happy if I can collaborate on this. clime > > 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 _______________________________________________ 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
