From Fedora Project Wiki
(21 intermediate revisions by 3 users not shown)
Line 55: Line 55:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1474836 #1474836]


== Detailed Description ==
== Detailed Description ==
Line 61: Line 61:
RPM 4.14 contains several improvements that needs to get released and integrated in Fedora:
RPM 4.14 contains several improvements that needs to get released and integrated in Fedora:
* Major macro engine bug fix + sanity work:
* Major macro engine bug fix + sanity work:
** macro scope simplification + enforcing
** Macro scope simplification + enforcing
** macro arguments expanded
** Macro arguments expanded
** nested lua macro scoping fixes
** Nested lua macro scoping fixes
** improved error reporting
** Improved error reporting
* Major header/package/signature rewrite:
* Major header/package/signature rewrite:
** major hardening work on header parsing
** Unified code path for all header read/import
** signature checking before header imports
** Major hardening work on header parsing
** support for multiple signatures per package
** Unified code path for all header/package signature checking
** support for configurable signature policies
** Signature checking before header imports
* Major debuginfo rewrite (already part of Rawhide)
** Support for multiple signatures per package
** Support for configurable signature policies
* Major debuginfo rewrite (covered by two other changes and already applied in F27)
** [[Changes/ParallelInstallableDebuginfo|Parallel Installable Debuginfo]]
** [[Changes/ParallelInstallableDebuginfo|Parallel Installable Debuginfo]]
** [[Changes/SubpackageAndSourceDebuginfo|Subpackage And Source Debuginfo]]
** [[Changes/SubpackageAndSourceDebuginfo|Subpackage And Source Debuginfo]]
Line 77: Line 79:
** Signals blocked throughout write transactions
** Signals blocked throughout write transactions
* SSD conservation mode
* SSD conservation mode
* (Some) support for reproducible builds
* Improved support for reproducible builds
* Group tag now is in free format
* RPMCALLBACK_ELEM_PROGRESS now carries index of header
* New RPMCALLBACK_ELEM_PROGRESS callback
* Support for OpenSSL as a one of crypto libraries used for digests/signatures (already part of F27)
* 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
* Support for rich dependencies coming out from dependency generators
* Whitespaces are now allowed to use in %include
* %include can contain paths with whitespaces
* pkgconfigdeps generator if used with pkgconf will not check dependencies declared in .pc recursively, but rather will print top-level ones
* Dependency generator for pkg-config files doesn't check dependencies in .pc recursively, but rather print top-level ones (if pkgconf is used)
* SHA256 is now default for header digests
* Header digests use SHA256 by default
* Improvements in Python dependency generator
* Improvements and stabilization of "ndb" ([[Changes/NewRpmDBFormat|New RPM DB Format database format]])
* Support for "with" rich-operator:
* Support for "with" rich-operator:
** Specifying version range dependencies
** Specifying version range dependencies
Line 94: Line 97:


== Scope ==
== Scope ==
* Proposal owners:  
* Proposal owners: Rebase RPM
<!-- 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?-->


Line 100: Line 103:
<!-- 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?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/6875 #6875] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Change affects whole distribution rather than deliverables<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- 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 -->


Line 140: Line 143:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Packagers will see better error messages with broken macro
* Packagers will see better error messages with broken macro
* Packagers will be able to use unexpanded arguments for macro (like <code>%atosetup %{?git:-n %{name}-%{commit}}</code>)
* Packagers will be able to use unexpanded arguments for macro (like <code>%autosetup %{?git:-n %{name}-%{commit}}</code>)
* Release Engineers / Packagers will be able to use multiple keys for signing packages
* 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
* Users will be able to install multiple versions of debuginfo packages at the same time
Line 148: Line 151:
* Packagers will be able to specify version range or "feature" dependencies (examples are below)
* Packagers will be able to specify version range or "feature" dependencies (examples are below)
** <code>Requires: (foo >= 1.0 with foo < 2.0)</code>
** <code>Requires: (foo >= 1.0 with foo < 2.0)</code>
** <code>Requires: (kernel with flavour = desktop)</code>
** <code>Requires: (kernel with flavor = desktop)</code>
* Packagers will stop missing autogenerated dependencies coming from pkg-config files if they don't have dependencies in buildroot
* Packagers will stop missing autogenerated dependencies coming from pkg-config files if they don't have dependencies in buildroot
* Users shouldn't see any regressions
* Users shouldn't see any regressions
* Users will be able to test tech-preview version of ndb (by changing <code>_db_backend</code> to <code>ndb</code> and running <code>rpmbuild --rebuild</code>)


== Dependencies ==
== Dependencies ==
Line 158: Line 162:
* New (and old) kind of rich dependencies (in Requires / Recommends) could be used only when FPC approves them
* 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
* Multiple keys per package might require some changes in DNF and/or Infrastructure
* Better reporting of processing package (RPMCALLBACK_ELEM_PROGRESS) through DNF API (e.g. in Anaconda) requires support from DNF
* Changing database from bdb to ndb requires patching of some programs who read/expect /var/lib/rpm/Packages and other files directly without using librpm


Nothing from above blocks implementing feature.
Nothing from above blocks implementing change.


== Contingency Plan ==
== Contingency Plan ==
Line 184: Line 190:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF27]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Revision as of 13:30, 25 July 2017


RPM 4.14

Summary

Update RPM to the upcoming 4.14 release.

Owner

Current status

Detailed Description

RPM 4.14 contains 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:
    • Unified code path for all header read/import
    • Major hardening work on header parsing
    • Unified code path for all header/package signature checking
    • Signature checking before header imports
    • Support for multiple signatures per package
    • Support for configurable signature policies
  • Major debuginfo rewrite (covered by two other changes and already applied in F27)
  • Signal handling rewrite:
    • Custom signal handlers while rpmdb open
    • Signals blocked throughout write transactions
  • SSD conservation mode
  • Improved support for reproducible builds
  • RPMCALLBACK_ELEM_PROGRESS now carries index of header
  • Support for OpenSSL as a one of crypto libraries used for digests/signatures (already part of F27)
  • Support for rich dependencies coming out from dependency generators
  • %include can contain paths with whitespaces
  • Dependency generator for pkg-config files doesn't check dependencies in .pc recursively, but rather print top-level ones (if pkgconf is used)
  • Header digests use SHA256 by default
  • Improvements in Python dependency generator
  • Improvements and stabilization of "ndb" (New RPM DB Format database format)
  • Support for "with" rich-operator:
    • Specifying version range dependencies
    • Specifying packages which provide special ability

Benefit to Fedora

The above plus closing the gap between RPM upstream and the Fedora version.

Scope

  • Proposal owners: Rebase RPM
  • 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: #6875 (a check of an impact with Release Engineering is needed)
  • 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 %autosetup %{?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
  • Packagers will be able to specify version range or "feature" dependencies (examples are below)
    • Requires: (foo >= 1.0 with foo < 2.0)
    • Requires: (kernel with flavor = desktop)
  • Packagers will stop missing autogenerated dependencies coming from pkg-config files if they don't have dependencies in buildroot
  • Users shouldn't see any regressions
  • Users will be able to test tech-preview version of ndb (by changing _db_backend to ndb and running rpmbuild --rebuild)

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
  • Better reporting of processing package (RPMCALLBACK_ELEM_PROGRESS) through DNF API (e.g. in Anaconda) requires support from DNF
  • Changing database from bdb to ndb requires patching of some programs who read/expect /var/lib/rpm/Packages and other files directly without using librpm

Nothing from above blocks implementing change.

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

Release Notes