(%release -> Release) |
m (→rpmautospec - removing release and changelog fields from spec files: small formatting fix) |
||
Line 9: | Line 9: | ||
Note: This proposal is about changing the way the `Release` and `%changelog` sections of the | Note: This proposal is about changing the way the `Release` and `%changelog` sections of the '''spec file''' are filled, not about removing them from the SRPM or binary RPM. | ||
== Owner == | == Owner == |
Revision as of 14:14, 11 February 2021
rpmautospec - removing release and changelog fields from spec files
Summary
The goal of this change is to deploy in production the 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 file are filled, not about removing them from the SRPM or binary RPM.
Owner
- Name: Pierre-Yves Chibon
- Email: pingou - at - pingoured.fr
- Name: Nils Philippsen
- Email: nphilipp - at - redhat.com
Current status
- Targeted release: N/A
- Last updated: 2021-02-11
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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 documentation of the autorel macro describes how packagers can use it to provide extra information.
The %autochangelog macro
The %autochangelog macro is in fact more a placeholder that rpmautospec fills in during the creation of the SRPM (or when ran manually on a project).
rpmautospec uses two sources of information to automatically generate the changelog:
- an optional
changelog
file that packagers can add to the repository - the git history of the spec file
rpmautospec will include the changelog
as is in the %changelog
section and will use all the commits made to the repository after the last change of the changelog
file to generate the changelog.
In other words, if the packager has a repository created on January 10th and works on it for 6 months, adds a changelog
file on June 1st. All the commits made before that commit of June 1st will be ignored in favor of the content of the changelog
file.
Similarly, if the packager then edits the file on July 1st, all the commits prior to that commit of July 1st will be ignored.
All the commits involving files ending with either ".spec" or ".patch" (this list can be expended if desired) and made after July 1st will be used to generate the changelog.
Feedback
Benefit to Fedora
In short: easier packaging in Fedora for the packagers who opt-in.
The Release
and %changelog
fields are the two most conflicting fields in RPM spec files. They impact most pull requests if they involve updating the package or if the package is updated/rebuilt while pull-request are being reviewed.
We currently have three different change logs per package and while they target different audiences (package maintainer: git, sysadmin: %changelog and end-user: bodhi notes) they overlap a lot and in most cases are redundant. With this proposal, package maintainers will only have to cope with two changelogs: git and bodhi notes.
Scope
- Proposal owners:
- Finish the work on the %autorel macro to support some of the use cases not implemented currently
- Adjust the packaging so rpmautospec does not live in a specific, versionized python environment (and thus could be use to bootstrap python)
- Adjust rpmdev-bumpspec (used by releng for mass-rebuilds) so it ignores spec files using %autorel/%autochangelog
- Adjust the mass-rebuild script so it only adds a suitable git commit log message for spec files using %autorel/%autochangelog
- Adjust fedpkg to skip the NEVR check when using rpmautospec
- Add dependency on rpmautospec on redhat-rpm-config
- Other developers:
- Opt-in for those who want to use it
- Test changes in staging
- Provide feedback
- Release engineering: #Releng issue number
- Policies and guidelines: Packaging guidelines should be adjust to explain how rpmautospec works and can be used. Documentation at: https://docs.pagure.org/fedora-infra.rpmautospec/ should provide a good basis for this
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: While not listed on the wiki page of that objective, it could be seen as related to https://fedoraproject.org/wiki/Objectives/Packager_Experience
Upgrade/compatibility impact
Not applicable
How To Test
In staging:
- Use
stg-koji
instead ofkoji
- Use
fedpkg-stage
instead offedpkg
(dnf install fedpkg-stage
)
- Run
kinit <accountname>@STG.FEDORAPROJECT.ORG
- Test with rawhide as rpmautospec is only available there in staging at this point
- Install
rpmautospec-rpm-macros
to build packages locally. - Edit the spec file to use either macro (or both)
- (Optional) Run
rpmautospec
on the git repository of your choice to see what it does (you may have to runrpmautospec tag-package
the first time you run it). - Build the package
- Check its release or changelog according to the macro set
In production:
- Edit the spec file to use either macro (or both)
- (Optional) Run
rpmautospec
on the git repository of your choice to see what it does (you may have to runrpmautospec tag-package
the first time you run it). - Build the package
- Check its release or changelog according to the macro set
Issues can be reported at: https://pagure.io/fedora-infra/rpmautospec/issues
Note that using this approach has some peculiarities, we've documented the ones we've encountered at: https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html
User Experience
Packagers not opting-in should not be affected in any way by this change.
Packagers opting-in should be able to stop worrying (or worry much less) about the content of the Release/%changelog fields in their spec file.
Dependencies
None
Contingency Plan
- Contingency mechanism: rpmautospec is not deployed in koji
- Contingency deadline: N/A (this isn't tied to a Fedora release)
- Blocks release? No
Documentation
All the upstream documentations can be https://docs.pagure.org/fedora-infra.rpmautospec/
Release Notes
N/A, this change will not affect end-users (except maybe for some changes in the content of the rpm changelog).