From Fedora Project Wiki

< Features

Revision as of 01:45, 5 June 2009 by Cweyl (talk | contribs) (Detailed Description)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Feature Name

Better RPM auto-req/prov filtering.


RPM has no general mechanism to enable filtering of auto-generated requires and provides; this feature aims to implement one.


Current status

  • Targeted release: Fedora 29
  • Last updated: (DATE)
  • Percentage of completion: 50%
    • working macros have been generated, but not included in the rpm package as of yet

Detailed Description

The auto requires and provides system contained in RPM is quite useful; however, it often picks up "private" package capabilities that shouldn't be advertised as global, or things that are "just wrong".

For example:

  • Various "plugin" packages (e.g. Pidgin, Perl, Apache, KDE) are marked as "providing" private shared libraries outside the system path.
  • Files in %{_docdir} are routinely scanned, and can trigger prov/req when this is explicitly forbidden by policy.

As it stands, filtering these auto-generated requires and provides is difficult and messy at best, and horribly deep magic in many cases; with little guidance on how to do it.[1] This feature aims to make the following tasks easy:

  • preventing files/directories from being scanned for requires (pre-scan filtering)
  • preventing files/directories from being scanned for provides (pre-scan filtering)
  • removing items from the requires stream (post-scan filtering)
  • removing items from the provides stream (post-scan filtering)

Suggested macros for creating the filtering system: macros.filtering

e.g. to ensure an arch-specific perl-* package won't provide or require things that it shouldn't, we could use an invocation as such:

# we don't want to provide private Perl extension libs
%filter_provides_in %{perl_vendorarch}/.*\\.so$ 
%filter_provides_in -P %{perl_archlib}/(?!CORE/libperl).*\\.so$ 

# we don't want to either provide or require anything from _docdir, per policy
%filter_provides_in %{_docdir} 
%filter_requires_in %{_docdir}

# actually set up the filtering


Or better yet, have all that centralized, so any package providing a Perl extension[2] can easily invoke the correct filtering incantations:



A brief comparison of other auto req/prov filtering systems.

Benefit to Fedora

While we should be filtering these "bad" provides out, in many cases we aren't, as the cure is often perceived as worse than the problem. For example, of the 273 noarch perl-* packages in rawhide as of today (31 May 2009), rpm has flagged 183 of them as "providing" shared libraries they shouldn't.

Direct benefits of having a simple filtering system in place and available to package maintainers would be to

  • directly cut down the number of provides our systems need to keep track of (koji, rpm, yum, etc);
  • prevent "requires" from being incorrectly satisfied; and
  • drastically reduce the complexity of this sort of filtering, by centralizing and standardizing it.

This isn't a theoretical concern, either: in rawhide as of 31 May 2009, there are

  • 7929 specs
  • 198 that override the internal dependency generator
  • 320 that override *_provides
  • 324 that override *_requires hundreds more where we should be filtering, but are not currently doing so.


  1. Append the macros in macros.filtering to /usr/lib/rpm/macros.
  2. Build and push new rpm packages :)

How To Test

Testing is straightforward: with the new filtering macros in /usr/lib/rpm/macros, try building a package and invoking the macros. Verify that whatever you're trying to filter does indeed not make it into the built rpm.

User Experience

This feature is not very "end user" noticable. The main things that may be noticed are:

  • faster yum/rpm, due to errant req/provs being removed from consideration; and
  • no package being installed for falsely "satisfying" another package's legitimate requires.


No external dependencies; once these macros are included they'll be available to packages seeking to employ them.

Contingency Plan

If this feature cannot be completed in time, we can simply omit any changes to /usr/lib/rpm/macros and retain the status quo.


No additional external documentation at this time. Once the macros are in place, we should update the packaging guidelines to reflect them.

Release Notes

"A new system for filtering auto-generated RPM provides and requires has been included with this release. This system will allow for a greater confidence in the accuracy of these auto provides/requires, as well as reducing the amount of package metadata retained by RPM and YUM."

Comments and Discussion

  1. Note.png Perl is a notable exception, with Packaging:Perl giving useful filtering examples; examples that are still complex and don't deal with the common cases of filtering out private shared libs or deps generated from files in %{_docdir}, however.
  2. Note.png Note this includes all the packages in the perl-* namespace, but also, say, *-perl, mod_perl, pidgin-perl, etc, etc.