From Fedora Project Wiki

< Changes

Revision as of 08:13, 18 February 2019 by Ignatenkobrain (talk | contribs)

Automatic strict inter-package dependencies

Summary

Implement feature in RPM which will enforce strict dependencies between subpackages automatically (right now packagers have to do it themselves).

Owner

  • Name: Igor Gnatenko
  • Email: ignatenkobrain@fedoraproject.org
  • Release notes owner:

Current status

  • Targeted release: Fedora 31
  • Last updated: 2019-02-18
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Let's take graphene as an example.

Spec file contains:

%package devel
Requires: %{name}%{?_isa} = %{version}-%{release}
%package tests
Requires: %{name}%{?_isa} = %{version}-%{release}

What we see when we build RPMs is:

  • graphene-devel requires graphene(x86-64) = 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit) AND pkgconfig(graphene-1.0)
  • graphene-tests requires graphene(x86-64) = 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit)

What can we do?

  • Requires: libgraphene-1.0.so.0()(64bit) is actually provided by graphene (coming from same package), so it can be dropped in favor of Requires: graphene(x86-64) = 1.8.2-3.fc30
  • Requires: pkgconfig(graphene-1.0) is provided by graphene-devel (coming from the same subpackage), so it can be dropped entirely

Benefit to Fedora

Package dependencies (between subpackages) will be more strict, more automated (this section from guidelines can be dropped entirely). Metadata size will decrease as well.

Scope

  • Proposal owners: Implement required feature in RPM, backport it to Fedora.
  • Other developers: Drop unneeded dependencies to keep spec file simpler.
  • Release engineering: #8128
  • Policies and guidelines: Drop yet another Packaging Guidelines section because it will be automated.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Everything will keep working.

How To Test

TBD.

User Experience

User's won't see packaging errors (wrt. inter-package dependencies) anymore.

Dependencies

RPM changes are needed. Will be handled by Proposal Owners.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Proposal Owners will try to fix problems ASAP or move Change to the next release (and revert changes).
  • Contingency deadline: Beta Freeze.
  • Blocks release? No.
  • Blocks product? No.

Documentation

TBD.

Release Notes