On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton <bcotton(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/rpmautospec
== Summary ==
The goal of this change is to deploy in production the
[
https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
project.
With it, the content of the `Release` and `%changelog` fields in spec
files can be auto-generated, either locally or in the builder using
the information present in the git repo (in the form of git tags).
Note: This proposal is about changing the way the `Release` and
`%changelog` sections of the '''spec files''' are filled, not
about
removing them from the SRPM or binary RPM.
== Owner ==
* Name: [[User:pingou| Pierre-Yves Chibon]]
* Email: pingou - at - pingoured.fr
* Name: [[User:nphilipp| Nils Philippsen]]
* Email: nphilipp - at -
redhat.com
== Detailed Description ==
rpmautospec offers packagers who want to use it the possibility of
replacing the content of the `Release` of their spec file by `Release:
%autorel` and/or replace the content of the `%changelog` section of
their spec file by:
%changelog
%autochangelog
Both `%autorel` and `%autochangelog` are RPM macros that will be
expanded or replaced when the SRPM is built on the build system by
their corresponding values according to rpmautospec.
An overview of how rpmautospec works can be found at:
https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
We will describe below how each macro works.
=== The %autorel macro ===
To determine the next release information, rpmautospec relies on the
build history of the package.
This information is extracted from the buildsystem when running as a
koji plugin and from git tags when running outside of the buildsystem.
Using the build history of the package (ie a list of NEVRs) as well as
the information provided by the packager in the spec file, rpmautospec
then computes the next best release number for the package.
Once defined, it prepends a suitably defined %autorel macro to the top
of the spec file, freezing the computed value of the release number
and thus allowing reproducible builds of the SRPM.
The [
https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
documentation of the autorel macro] describes how packagers can use it
to provide extra information.
I wonder why you're not relying solely on git history for both local
builds and in koji?
When this stuff was last discussed last year, I tried to implement a
simple algorithm for automatic Release values as well (because why
not), and I even had a working proof-of-concept implementation (in
python + pygit2) for the Release number that even worked for
non-linear git histories, something like (python-esque-pseudocode):
def release_num(commit, last_version) -> int:
if version_at(commit) != last_version:
return 0
else:
return max(release_num(parent, last_version) for parent of commit)) +1
(With "version_at" being a function that returns the value of Version
tag present in the specified commit in the git history.)
With an algorithm like this, you would not need to rely on either
build history or git tags, but use *only* commit history - which
should make this more reliable and produce always the same results
locally *and* in koji (because it uses the same underlying data).
Fabio