On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton <bcot...@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
