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(a)fedoraproject.org> 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/m...
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