From Fedora Project Wiki
< Changes
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...") |
No edit summary |
||
| Line 25: | Line 25: | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
Update RPM to the upcoming 4.14 release. | |||
== Owner == | == Owner == | ||
| Line 57: | Line 58: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
RPM 4.14 ucontains several improvements that needs to get released and integrated in Fedora: | |||
* Major macro engine bug fix + sanity work: | |||
- macro scope simplification + enforcing | |||
- macro arguments expanded | |||
- nested lua macro scoping fixes | |||
- improved error reporting | |||
* Major header/package/signature rewrite: | |||
- major hardening work on header parsing | |||
- signature checking before header imports | |||
- support for multiple signatures per package | |||
- support for configurable signature policies | |||
* Major debuginfo rewrite (already part of Rawhide) | |||
- [[Changes/ParallelInstallableDebuginfo|Parallel Installable Debuginfo]] | |||
- [[Changes/SubpackageAndSourceDebuginfo|Subpackage And Source Debuginfo]] | |||
* Signal handling rewrite: | |||
- Custom signal handlers while rpmdb open | |||
- Signals blocked throughout write transactions | |||
* SSD conservation mode | |||
* (Some) support for reproducible builds | |||
* Group tag now is in free format | |||
* New RPMCALLBACK_ELEM_PROGRESS callback | |||
* Support for OpenSSL as a one of crypto libraries used for digests/signatures (already part of Rawhide) | |||
* Support for rich dependencies coming out from dependency generators | |||
* Whitespaces are now allowed to use in %include | |||
* pkgconfigdeps generator if used with pkgconf will not check dependencies declared in .pc recursively, but rather will print top-level ones | |||
* SHA256 is now default for header digests | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
The above plus closing the gap between RPM upstream and the Fedora version. | |||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: | * Other developers: Test new release, report issues and bugs, fix bugs in packaging (if it is not bug in RPM, should be detected during Mass Rebuild) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 79: | Line 103: | ||
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | ||
* Policies and guidelines: | * Policies and guidelines: FPC should look (and possibly approve) "with" rich dependency in Packaging Guidelines <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- 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. --> | <!-- 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. --> | ||
| Line 89: | Line 113: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Using some of the new feature will break forward compatibility. Packages using these features will not be able be build or be installed on older Fedora versions. Backward compatibility is expected to be maintained. | |||
== How To Test == | == How To Test == | ||
| Line 107: | Line 131: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Testing is done in full operation. | |||
== User Experience == | == User Experience == | ||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Packagers will see better error messages with broken macro | |||
* Packagers will be able to use unexpanded arguments for macro (like %atosetup %{?git:-n %{name}-%{commit}}) | |||
* Release Engineers / Packagers will be able to use multiple keys for signing packages | |||
* Users will be able to install multiple versions of debuginfo packages at the same time | |||
* Packagers will be able to split debuginfo per (sub-)package and one debugsource for package | |||
* Release Engineers will be able to make reproducible builds easier | |||
* Packagers will be able to write dependency generators which returns rich dependencies | |||
* Packars will be able to specify version range or "feature" dependencies (examples are below) | |||
- Requires: (foo >= 1.0 with foo < 2.0) | |||
- Requires: (kernel with flavour = desktop) | |||
* Users shouldn't see any regressions | |||
== Dependencies == | == Dependencies == | ||
| Line 118: | Line 152: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* New (and old) kind of rich dependencies (in Requires / Recommends) could be used only when FPC approves them | |||
* Multiple keys per package might require some changes in DNF and/or Infrastructure | |||
Nothing from above blocks implementing feature. | |||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) | * Contingency mechanism: (What to do? Who will do it?) Fix issues quickly / Go back to rpm-4.13. It is unlikely that this requires reverting some changes in other packages as the new features will probably not already be used in F27. In case something really bad happens it might be necessary to rebuild all packages built with the broken version <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: | * Contingency deadline: Alpha Release <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? Yes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Blocks product? | * Blocks product? - <!-- Applicable for Changes that blocks specific product release/Fedora.next --> | ||
== Documentation == | == Documentation == | ||
| Line 134: | Line 171: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Release notes (will be ready once 4.14 releases): http://rpm.org/wiki/Releases/4.14.0 | |||
== Release Notes == | == Release Notes == | ||
Revision as of 07:43, 3 July 2017
RPM 4.14
Summary
Update RPM to the upcoming 4.14 release.
Owner
- Name: Igor Gnatenko, Florian Festi, Panu Matilainen
- Email: ignatenkobrain@fedoraproject.org, ffesti@redhat.com, pmatilai@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 27
- Last updated: 2017-07-03
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
RPM 4.14 ucontains several improvements that needs to get released and integrated in Fedora:
- Major macro engine bug fix + sanity work:
- macro scope simplification + enforcing - macro arguments expanded - nested lua macro scoping fixes - improved error reporting
- Major header/package/signature rewrite:
- major hardening work on header parsing - signature checking before header imports - support for multiple signatures per package - support for configurable signature policies
- Major debuginfo rewrite (already part of Rawhide)
- Parallel Installable Debuginfo - Subpackage And Source Debuginfo
- Signal handling rewrite:
- Custom signal handlers while rpmdb open - Signals blocked throughout write transactions
- SSD conservation mode
- (Some) support for reproducible builds
- Group tag now is in free format
- New RPMCALLBACK_ELEM_PROGRESS callback
- Support for OpenSSL as a one of crypto libraries used for digests/signatures (already part of Rawhide)
- Support for rich dependencies coming out from dependency generators
- Whitespaces are now allowed to use in %include
- pkgconfigdeps generator if used with pkgconf will not check dependencies declared in .pc recursively, but rather will print top-level ones
- SHA256 is now default for header digests
Benefit to Fedora
The above plus closing the gap between RPM upstream and the Fedora version.
Scope
- Proposal owners:
- Other developers: Test new release, report issues and bugs, fix bugs in packaging (if it is not bug in RPM, should be detected during Mass Rebuild)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: FPC should look (and possibly approve) "with" rich dependency in Packaging Guidelines
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Using some of the new feature will break forward compatibility. Packages using these features will not be able be build or be installed on older Fedora versions. Backward compatibility is expected to be maintained.
How To Test
Testing is done in full operation.
User Experience
- Packagers will see better error messages with broken macro
- Packagers will be able to use unexpanded arguments for macro (like %atosetup %{?git:-n %{name}-%{commit}})
- Release Engineers / Packagers will be able to use multiple keys for signing packages
- Users will be able to install multiple versions of debuginfo packages at the same time
- Packagers will be able to split debuginfo per (sub-)package and one debugsource for package
- Release Engineers will be able to make reproducible builds easier
- Packagers will be able to write dependency generators which returns rich dependencies
- Packars will be able to specify version range or "feature" dependencies (examples are below)
- Requires: (foo >= 1.0 with foo < 2.0) - Requires: (kernel with flavour = desktop)
- Users shouldn't see any regressions
Dependencies
- New (and old) kind of rich dependencies (in Requires / Recommends) could be used only when FPC approves them
- Multiple keys per package might require some changes in DNF and/or Infrastructure
Nothing from above blocks implementing feature.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) Fix issues quickly / Go back to rpm-4.13. It is unlikely that this requires reverting some changes in other packages as the new features will probably not already be used in F27. In case something really bad happens it might be necessary to rebuild all packages built with the broken version
- Contingency deadline: Alpha Release
- Blocks release? Yes
- Blocks product? -
Documentation
Release notes (will be ready once 4.14 releases): http://rpm.org/wiki/Releases/4.14.0