On Tue, Feb 16, 2021 at 02:48:23PM +0100, Fabio Valentini wrote: > 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? To prevent accidental divergence between the git history and the build system. That's why this information is only used in the koji plugin, locally (ie: via the rpmautospec CLI) it only relies on the git tags. Using the number of commits can give weird results with merge commits and even though the upgrade path is not really an issue anymore, we preferred to try preserving it. So rpmautospec should minimize the risk of broken upgrade path. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
