On Tue, 25 Feb 2020 at 12:47, clime <clime@xxxxxxxxxxxxxxxxx> wrote: > > 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 Sry for the weird line breaks, i need to tweak my mail "client" not to do that. > > > > > 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
