Rpmautospec by Default
Summary
Rpmautospec (%autorelease
and %autochangelog
) is recommended as the default approach.
Packaging Guidelines and other documentation are adjusted to describe this approach first.
Various tools that provide spec file templates are adjusted.
Owner
- Name: Nils Philippsen, Zbigniew Jędrzejewski-Szmek, Otto Liljalaakso, Stephen Gallagher
- Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl, otto.liljalaakso - at - iki.fi, sgallagh - at - redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2023-11-21
- devel thread
- FESCo issue: #2930
- Tracker bug: #2161756
- Release notes tracker: <will MOT be assigned by the Wrangler - not user-visible>
Detailed Description
Rpmautospec has been deployed in Fedora since F35 (Changes/rpmautospec), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to %autorelease
+%autochangelog
for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed Release
and %changelog
will remain valid and will be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope.
It is worth mentioning that rust2rpm
uses %autorelease
+%autochangelog
since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.)
Feedback
- Thread on fedora-devel in August 2022: rpmautospec by default
- open issues: a bunch have been fixed.
- maintenance: Nils will add some co-maintainers.
- compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section.
Benefit to Fedora
Various packaging workflows become smoother for packagers and contributors:
- packagers don't need to touch the
Release
field on updates - packagers describe changes just once in the git commit message, the
%changelog
entry is autogenerated - patches to the spec file can be cherry-picked between branches without trivial conflicts
- pull requests on src.fedoraproject.org can be merged without trivial conflicts
- in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
%changelog
section doesn't need to be copied over
Scope
- Proposal owners:
- provide pull requests to Packaging Guidelines and other docs to make
%autorelease
+%autochangelog
the default - implement fixes for issues reported by packagers
- make semi-regular releases of rpmautospec (0.3.1 was released on November 17th, and should be deployed to production in about two weeks)
- provide pull requests to Packaging Guidelines and other docs to make
- Other developers:
- provide pull requests to other docs as appropriate
- accept the changes to documentation
- update other spec file generators (pip2rpm, gem2rpm, others?)
- Somebody (TBD):
fedora-review
—https://pagure.io/rpkg/issue/641fedpkg import
— with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores%autorelease
+%autochangelog
in the file committed to dist-git needs to be implemented.- Support no-change commits in
fedpkg
(fedpkg commit -m 'Rebuild'
) — issue #494, MERGED
- Related work
- Release engineering: #Releng issue number
- Policies and guidelines: a list of places to be updated
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: N/A
Upgrade/compatibility impact
Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway.
How To Test
- Convert an existing package:
rpmautospec convert
. Ideally this step is done right before a version bump so that the release numbers restart at-1
. - Do local builds (
fedpkg local
,fedpkg mockbuild
). Verify correctness of version-release (rpm -qpi
) and the changelog (rpm -qp --changelog
). - Do builds in koji. Verify correctness of version-release and the changelog.
- For new packages, use
%autorelease
+%autochangelog
. Repeat all the tests listed above.
- Assume you are a newbie packager. Read the packaging docs and check that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly.
User Experience
No changes visible to end users.
Dependencies
None.
Contingency Plan
If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation.
- Contingency mechanism: Revert changes to documentation by reverting the appropriate commits. This can be done easily by FPC.
- Contingency deadline: Any time.
- Blocks release? No.
Documentation
This page and any changes to Packaging Guidelines and other documents.
Release Notes
Not needed.