From Fedora Project Wiki
Line 85: Line 85:
* pkgconfigdeps generator if used with pkgconf will not check dependencies declared in .pc recursively, but rather will print top-level ones
* 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
* SHA256 is now default for header digests
* Support for "with" rich-operator:
** Specifying version range dependencies
** Specifying packages which provide special ability


== Benefit to Fedora ==
== Benefit to Fedora ==

Revision as of 07:52, 3 July 2017


RPM 4.14

Summary

Update RPM to the upcoming 4.14 release.

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)
  • 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
  • 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:
  • 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)
  • 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
  • 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 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

Release Notes