Features/BetterRpmAutoReqProvFiltering

From FedoraProject

Jump to: navigation, search


Contents

Feature Name

Better RPM auto-req/prov filtering.

Summary

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

Owner

Current status


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:

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:

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
%filter_setup

%description
...

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

%{?perl_default_filter}

%description
...

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

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

...plus hundreds more where we should be filtering, but are not currently doing so.

Scope

  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:

Dependencies

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.

Documentation

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.