Automatic Filtering of Provides and Requires
Summary
The auto requires and provides system contained in RPM is quite useful;
however, it sometimes picks up "private" package capabilities
that shouldn’t be advertised as global,
things that are "just wrong",
or things prohibited by policy (e.g. deps from inside %{_docdir}
).
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.
This Guideline describes how to filter provides and requires on Fedora.
-
MUST: Packages must not provide RPM dependency information when that information is not global in nature, or are otherwise handled (e.g. through a virtual provides system). e.g. a plugin package containing a binary shared library must not "provide" that library unless it is accessible through the system library paths.
-
MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it.
Usage
Location of macro invocation
It’s strongly recommended
that these filtering macros be invoked before %description
,
but after any other definitions.
This will keep them in a consistent place across packages,
and help prevent them from being mixed up with other sections.
Regular Expression Variant
These filters use regular expressions.
The regular expression variant used for these filters
follows the POSIX.2
regular expression standard
(see the +regex(7)
manpage).
In this variant,
the literal characters ^.[$()|*+?{
need to be backslash escaped.
Because rpm interprets backslashes as part of its parsing of spec files,
you will need to use a double backslash for any escapes.
A literal backslash (“\”) is represented by four backslashes.
The regex engine is only passed the final string, after RPM macro expansion.
So you can’t use unescaped data via RPM macros.
For instance, if you generate a list of files to match in a macro
and that list contains libfoo.so
you’ll have to use libfoo\\.so
to escape the (“.”).
Example:
%global to_exclude libfoo\\.so
%global __requires_exclude_from ^%{_datadir}/%{to_exclude}$
Preventing files/directories from being scanned for deps (pre-scan filtering)
The macros %__requires_exclude_from
and %__provides_exclude_from
can be defined in a spec file to keep the dependency generator
from scanning specific files or directories for deps.
These macros should be defined with a regular expression
that matches all of the directories or files.
For instance:
# Do not check any files in docdir for requires
%global __requires_exclude_from ^%{_docdir}/.*$
# Do not check .so files in an application-specific library directory
# or any files in the application's data directory for provides
%global __provides_exclude_from ^(%{_libdir}/%{name}/.*\\.so.*|%{_datadir}/myapp/.*)$
Note that this macro replaces the %filter_provides_in
macro
from the old filtering guidelines but it does not do the same thing.
In particular:
-
The old macro could be invoked multiple times. This one will only use the regex defined last.
-
The old macro advised against anchoring the beginning of the regex (Using
^
). This macro recommends anchoring as it doesn’t suffer from the compatibility problems of the old one. -
With the old macro it was common to specify a directory name to match everything in a directory recursively. With the new macro you may need to specify
.*
because you should be anchoring your regular expressions.
Filtering provides and requires after scanning
In addition to preventing RPM from scanning
files and directories for automatic dependency generation
you can also tell RPM to discard a discovered dependency
before it records the dependency in the RPM metadata.
Use __requires_exclude
and __provides_exclude
for this.
These macros should be defined as regular expressions.
If an entry that RPM’s automatic dependency generator created
matches the regular expression
then it will be filtered out of the requires or provides.
For example:
# This might be useful if plugins are being picked up by the dependency generator
%global __provides_exclude ^libfoo-plugin\\.so.*$
# Something like this could be used to prevent excess deps from an
# example python script in %doc
%global __requires_exclude ^/usr/bin/python$
These macros serves a similar purpose to the old
%filter_from_provides
macro
but it has a different implementation.
In particular,
that macro took sed expressions whereas this one needs a regular expression.
Simplified macros for common cases
In some cases, the filtering of extraneous Provides:
is fairly generic to all packages which provide similar things.
There are simple macros that setup filters correctly
for those cases so that you can do the filtering with one line.
If you need to filter a bit more than the simple macro provides,
you still have the option to use the macros listed above.
Perl
Perl extension modules can be filtered using this macro:
%{?perl_default_filter}
Essentially, this filters dependencies arising from %doc
files,
from non-Linux-related modules,
and from errors in the automatic dependency generator.
If you want to use both custom filters and %perl_default_filter
then define your filters first and call %perl_default_filter
afterwards.
The default filter macro will preserve the filters you previously defined.
For example:
# Filter all provides from some directory
%global __provides_exclude_from %{_libexecdir}/autoinst
# Filter some specific requires by name
%global __requires_exclude ^perl\\((autotest|basetest)
# All of the default filters
%{?perl_default_filter}
Examples
Pidgin plugin package
On a x86_64 machine,
the pidgin-libnotify provides pidgin-libnotify.so()(64bit)
which it shouldn’t as this library is not inside the paths
searched by the system for libraries.
It’s a private, not global, "provides"
and as such must not be exposed globally by RPM.
To filter this out, we could use:
%global __provides_exclude_from ^%{_libdir}/purple-2/.*\\.so$
Private Libraries
At this time, filtering of private libraries is non-trivial.
This is because the symbols you want to filter from the private libraries
are usually required by the public applications that the package ships.
In order to filter,
you need to find out what symbols RPM is extracting for the private library
and then remove those in both
%__provides_exclude
and %__requires_exclude
.
As an example, pretend you are packaging an application foo that creates
%{_libdir}/foo/libprivate.so
that you want to filter and
%{_bindir}/foobar
that requires that private library.
You could:
-
First build the RPM:
$ rpmbuild -ba foo.spec
-
then determine what provides rpm decided for the private library:
$ rpm -qp foo-1.0-1.x86_64.rpm
:
libprivate.so()(64bit) foo = 1.0-1.fc19 foo(x86-64) = 1.0-1.fc19
-
See that
libprivate.so()(64bit)
appears to be the only symbol that RPM extracted for this package. Note that on 32bit, the provides will belibprivate.so
so your regex needs to capture both. -
Add the excludes to the spec file for both requires and provides:
[...]
%global _privatelibs libprivate[.]so.*
%global __provides_exclude ^(%{_privatelibs})$
%global __requires_exclude ^(%{_privatelibs})$
[...]
You can take a look at a more complex example on the mailing list. This can be a pain to maintain if the upstream changes the names of its private libraries but it is the only way to deal with this at present. There may be a better means in the future but there are no solid plans on when those might be coded as of yet..
Arch-specific extensions to scripting languages
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
%{?perl_default_filter}
%{_docdir}
filtering
By policy, nothing under %{_docdir}
is allowed
to either "provide" or "require" anything.
We can prevent this from happening
by preventing anything under %{_docdir}
from being scanned:
# we don't want to either provide or require anything from _docdir, per policy
%global __provides_exclude_from ^%{_docdir}/.*$
%global __requires_exclude_from ^%{_docdir}/.*$
Additional Information
Additional information about RPM’s dependency generator can be found here: https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
Want to help? Learn how to contribute to Fedora Docs ›