On Fri, Feb 12, 2021 at 5:20 PM Ben Cotton <bcotton@xxxxxxxxxx> 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@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
