There are 56 packages that use something like this:
%global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$ %global __provides_exclude_from ^(%{python2_sitearch}/.*\\.so)$ %global __provides_exclude_from ^(%{python3_sitearch}/.*\\.so)$ %global __provides_exclude_from ^(%{python2_sitearch}|%{python3_sitearch})/.*\\.so$ ...
and 68 like this:
%filter_provides_in %{python_sitearch}/whatnot/.*\.so$ %filter_provides_in %{python2_sitearch}/.*\.so$ %filter_provides_in %{python2_sitearch}/.*\.so$ %{python3_sitearch}/.*\.so$ ...
The full list can be obtained by:
$ rg '(filter_provides_in|__provides_exclude_from).*python'
This is not needed on Fedora and to my knowledge also not on EL7.
so
I propose we get rid of it on Fedora. Before I propose a mass spec change (maybe only __requires_exclude_from, because that's not available on EL6), we need to kill it from the guidelines.
__requires_exclude_from
Python Guidelines say:
RPM's dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. See Packaging:AutoProvidesAndRequiresFiltering for details.
AutoProvidesAndRequiresFiltering has this example:
# Do not check .so files in the python2_sitearch directory # or any files in the application's directory for provides %global __provides_exclude_from ^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$
And:
A recipe for python:
# we don't want to provide private python extension libs in either the python2 or python3 dirs %global __provides_exclude_from ^(%{python2_sitearch}|%{python3_sitearch})/.*\\.so$
Anything Python related should only be in EPEL:Packaging_Autoprovides_and_Requires_Filtering.
I think we should get rid out of all this cruft in Fedora and move that specific case to EPEL guidelines.
We could also add %{?python_default_filter} (similar to %{?perl_default_filter}) into EPEL6 for people to use if they like to.
%{?python_default_filter}
%{?perl_default_filter}
I've actually wanted that python_default_filter macro for some time now.
I have no problem moving this to the EPEL guidelines and adding a macro for the benefit of EPEL6 but at this point I've lost most of my knowledge about how the old-style dep filtering works.
We did talk about this in the meeting and since the changes are merely "remove needless cruft" I went ahead and deleted that needless cruft.
If we do want python_default_filter in EPEL6, someone please just file a PR against epel-rpm-macros or python-rpm-macros (whichever makes more sense, I guess the latter). I can mention that in the EPEL guidelines once it exists.
In any case, I think this is done.
Metadata Update from @tibbs: - Issue assigned to tibbs - Issue close_status updated to: fixed - Issue priority set to: None (was: Needs Review) - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.