From Fedora Project Wiki
< Changes
(Initial rpm 4.17 change draft) |
m (Clarifications etc) |
||
| Line 3: | Line 3: | ||
== Summary == | == Summary == | ||
Update RPM to the 4.17 release. | Update RPM to the [https://rpm.org/wiki/Releases/4.17.0 4.17] release. | ||
== Owner == | == Owner == | ||
* Name: [[User:pmatilai|Panu Matilainen]] | * Name: [[User:pmatilai|Panu Matilainen]] | ||
* Email pmatilai@redhat.com | * Email: [pmatilai@redhat.com] | ||
== Current status == | == Current status == | ||
| Line 32: | Line 32: | ||
== Detailed Description == | == Detailed Description == | ||
RPM 4.17 contains numerous improvements over previous versions | RPM 4.17 contains numerous improvements over previous versions | ||
* | * More robust install failure handling | ||
* Many macro improvements, in particular much improved Lua integration | * Many macro improvements, in particular much improved Lua integration | ||
* Strict checking for unpackaged content in builds | * Strict checking for unpackaged content in builds | ||
* Libraries no longer need executable permission for dependency generation and is automatically removed for non-executable libraries | |||
* Long needed transaction APIs enhancements | * Long needed transaction APIs enhancements | ||
* Improved documentation | * Improved documentation | ||
| Line 42: | Line 43: | ||
** Split language-specific packaging aids to separate projects (Python, Perl, Ocaml...) | ** Split language-specific packaging aids to separate projects (Python, Perl, Ocaml...) | ||
** Dynamic spec generation | ** Dynamic spec generation | ||
The plan is to get 4.17-alpha into rawhide as early as possible to sort out any initial rough edges long before the general feature deadline rush. Final version is expected to be released well in time before F35 beta. | |||
== Feedback == | == Feedback == | ||
| Line 49: | Line 52: | ||
See description for overall benefits, but in particular: | See description for overall benefits, but in particular: | ||
* All users benefit from the more robust installation | * All users benefit from the more robust installation | ||
* Packaging sanity wrt libraries | |||
* Macro authors will have a much saner experience creating complex macros in Lua | * Macro authors will have a much saner experience creating complex macros in Lua | ||
* DNF for the enhanced transaction APIs | * DNF for the enhanced transaction APIs | ||
| Line 61: | Line 65: | ||
** Adjust packaging to adhere to the strict buildroot content checking | ** Adjust packaging to adhere to the strict buildroot content checking | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/10072 #10072] | ||
* Policies and guidelines: | |||
** Guidelines have nothing on unpackaged contents in buildroot, so don't necessarily need updating. Many packages will fail to build because of the stricter checking though: with rpm >= 4.17 unpackaged content is not permitted in the buildroot at all. | |||
** Libraries no longer need to be executable for dependency generation, and executable bit will in fact be removed if invalidly set on a library. Guidelines only have a vague "executable if appropriate" mention so it does not *need* changing but could now be clarified/tightened if desired. | |||
* | |||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. --> | ||
| Line 74: | Line 77: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
* Many existing packages will fail to build due to the | * Many existing packages will fail to build due to the stricter buildroot content checking. Fixing this in the packaging is always backwards compatible. | ||
* Rpm no longer implicitly creates databases on read-only access, this may require changes to existing scripts/tooling | * Rpm no longer implicitly creates databases on read-only access, this may require changes to existing scripts/tooling. Ensuring mock/dnf works is a pre-requisite to landing this change into rawhide, and will be handled, one way or the other, by the rpm maintainers. | ||
== How To Test == | == How To Test == | ||
| Line 84: | Line 87: | ||
== Dependencies == | == Dependencies == | ||
* dnf and/or mock will likely need some adjusting for the lack of implicit database creation | * dnf and/or mock will likely need some adjusting for the lack of implicit database creation. If necessary, rpm maintainers will provide patches prior to landing this change. | ||
* soname bump is not expected so rebuilds should not be required | |||
== Contingency Plan == | == Contingency Plan == | ||
Revision as of 10:42, 31 March 2021
Change Proposal Name
RPM 4.17
Summary
Update RPM to the 4.17 release.
Owner
- Name: Panu Matilainen
- Email: [pmatilai@redhat.com]
Current status
- Targeted release: Fedora Linux 35
- Last updated: 2021-03-31
- 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
RPM 4.17 contains numerous improvements over previous versions
- More robust install failure handling
- Many macro improvements, in particular much improved Lua integration
- Strict checking for unpackaged content in builds
- Libraries no longer need executable permission for dependency generation and is automatically removed for non-executable libraries
- Long needed transaction APIs enhancements
- Improved documentation
- Tentative (planned but not committed as of this writing)
- Split debugedit to its own project and package
- Split language-specific packaging aids to separate projects (Python, Perl, Ocaml...)
- Dynamic spec generation
The plan is to get 4.17-alpha into rawhide as early as possible to sort out any initial rough edges long before the general feature deadline rush. Final version is expected to be released well in time before F35 beta.
Feedback
Benefit to Fedora
See description for overall benefits, but in particular:
- All users benefit from the more robust installation
- Packaging sanity wrt libraries
- Macro authors will have a much saner experience creating complex macros in Lua
- DNF for the enhanced transaction APIs
Scope
- Proposal owners:
- Rebase RPM
- Assist with dealing with incompatibilities
- Other developers:
- Test new release, report issues and bugs
- Adjust packaging to adhere to the strict buildroot content checking
- Release engineering: #10072
- Policies and guidelines:
- Guidelines have nothing on unpackaged contents in buildroot, so don't necessarily need updating. Many packages will fail to build because of the stricter checking though: with rpm >= 4.17 unpackaged content is not permitted in the buildroot at all.
- Libraries no longer need to be executable for dependency generation, and executable bit will in fact be removed if invalidly set on a library. Guidelines only have a vague "executable if appropriate" mention so it does not *need* changing but could now be clarified/tightened if desired.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: no relation to current objectives
Upgrade/compatibility impact
- Many existing packages will fail to build due to the stricter buildroot content checking. Fixing this in the packaging is always backwards compatible.
- Rpm no longer implicitly creates databases on read-only access, this may require changes to existing scripts/tooling. Ensuring mock/dnf works is a pre-requisite to landing this change into rawhide, and will be handled, one way or the other, by the rpm maintainers.
How To Test
Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation.
User Experience
The user-experience remains largely as-is, but install failures are handled more gracefully.
Dependencies
- dnf and/or mock will likely need some adjusting for the lack of implicit database creation. If necessary, rpm maintainers will provide patches prior to landing this change.
- soname bump is not expected so rebuilds should not be required
Contingency Plan
- Contingency mechanism: Revert back to RPM 4.16, but the risk of having to do should be negligible
- Contingency deadline: Beta freeze
- Blocks release? No
Documentation
Work-in-progress release notes at https://rpm.org/wiki/Releases/4.17.0 and reference manual at https://github.com/rpm-software-management/rpm/blob/master/doc/manual/index.md