Zen

Source string Source string

8/10000 · 8

The string is read only.

English Actions
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 be `+libprivate.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 https://lists.fedoraproject.org/pipermail/devel/2012-June/169190.html[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 https://lists.osuosl.org/pipermail/rpm-maint/2013-January/003349.html[the future] but there are no solid plans on when those might be coded as of yet..
Arch-specific extensions to scripting languages

Loading…

User avatar None

Source string added
Examples
4 years ago
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Inconsistent: Finnish, Portuguese (Brazil)

Reset

Glossary

English English
No related strings found in the glossary.

1005041 String information

Source string description
type: Title ==
Flags
no-wrap, read-only
Source string location
./pages/AutoProvidesAndRequiresFiltering.adoc:168
String age
4 years ago
Last updated
a year ago
Source string age
4 years ago
Translation file
pot/master/pages/AutoProvidesAndRequiresFiltering.pot, string 38