Zen

Translation

English type: Title ==
Examples
8/100 · 8

Sign in to save translations.

English Portuguese (Brazil) 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
Exemplos
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
 
User avatar anonymous

Suggestion added

Exemplos

Suggested change:

Exemplos
4 years ago

Loading…

User avatar farribeiro

Marked for edit
Examples
Exemplos
4 years ago
User avatar farribeiro

Suggestion accepted
Examples
Exemplos
4 years ago
User avatar farribeiro

Contributor joined
Contributor joined 4 years ago
User avatar None

Suggestion added
Examples
Exemplos
4 years ago
Browse all string changes

Things to check

Suggestions

There is 1 suggestion for this string.

View

Inconsistent

This string has more than one translation in this project or is untranslated in some components.

Reset

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

5989086 String information

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