RFE: elfdeps: Filter Python subdirectories

[hroncok]

I'd like the elfdeps to filter out certain directories, namely anything in /usr/lib(64)?/pythonX.Y/.

Context:

• historically, all Python extension modules needed to use %filter_provides_in %{python_sitearch}/.*\.so$ to avoid getting useless provides
• later, this practice shifted to %global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$
• later (73bd963), Python extension modules that don't start with lib... are no longer needed to be filtered out, hence this practice slowly dies

But we cannot get rid of this historical cruft totally, because some packages have Python extension modules named "lib...":

/usr/lib64/python3.8/site-packages/libexiv2python.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libhivexmod.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libxtwrapper.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libiscsi.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libxml2mod.so
/usr/lib64/python3.8/site-packages/liblo.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libPyROOT.cpython-38-x86_64-linux-gnu.so
/usr/lib64/python3.8/site-packages/libtorrent.cpython-38-x86_64-linux-gnu.so

An in turn they either need to filter the provides (which most current Python packagers don't know, unless they have some historical background of 7+ years), or they have bogus provides:

libexiv2python.cpython-38-x86_64-linux-gnu.so()(64bit)
libhivexmod.cpython-38-x86_64-linux-gnu.so()(64bit)
libxtwrapper.cpython-38-x86_64-linux-gnu.so()(64bit)
libiscsi.cpython-38-x86_64-linux-gnu.so()(64bit)
libxml2mod.so()(64bit)
liblo.cpython-38-x86_64-linux-gnu.so()(64bit)
libPyROOT.so.6.20()(64bit)
libtorrent.cpython-38-x86_64-linux-gnu.so()(64bit)

I'd like that no such provides are generated. Easiest way forward is to simply ignore the directories. I am fine with working on a pull request for this, but I'd like to discuss first on what level we should have the directories defined. Would it work if the tool had an --exclude argument that would take a path regex to exclude and we would define that to ^%{_prefix}/lib(64)?/python\d+\.\d+/ in elf.attr?

[pmatilai]

Problem is well known, but adding Python (or Perl, or whatever) specifics to elf.attr is not ok.
This needs something on the file classifier level.

Maybe some kind of anti-classifier directive or something. Thinking in the lines of, technically an ELF file is an ELF regardless of where it is on the filesystem, but if there was a way express "not elf" in Python/Perl/etc this would allow dealing with it more locally, but then everybody would need to roll their own version of handling the concrete ELF dependencies that are there regardless. There might be multiple cases for the "not foo" pattern, but it might also be too big a hammer for some/many of them.

[hroncok]

anti-classifier directive is totally fine by me.

[hroncok]

%__NAME_path_exclude

?

[hroncok]

However of course, in this particular case, we only want the provides to be filtered, not requires. If /usr/lib64/python3.8/site-packages/libiscsi.cpython-38-x86_64-linux-gnu.so links to libiscsi.so.0, we still want the package to require it. So setting a negative path filter in elf.attr would not work as intended :(

[pmatilai]

Yeah negating the entire ELF class would require handling (some of) it in the python generator instead. It's a blunt tool, maybe suitable for something but we do need something more subtle to correctly and sanely handle this.

[hroncok]

I was thinking how to handle this today. I've only figured out wrong solutions:

1. Modify %__global_provides_exclude_from to include %{_libdir}/python\d+\.\d+/.+\.so.
   This obviously has several problems: I cannot really do it from Python macros, so the information would need to be kept in the general macros file. Also, if we ever start providing something from those .so files, this would no longer work. Also, it does not scale well.

2. Negate the entire ELF generator on the specific paths and provide alternate ELF requires generator (without provides) for them. That seems like an awful "copy paste stuff around" hack, ale not sure how to detect the need to do this.

3. Extend RPM generators to be able to specify different %__NAME_provides_exclude_path, %__NAME_requires_exclude_path instead of general %__NAME_exclude_path and set %__elf_provides_exclude_path to %{_libdir}/python\d+\.\d+/.+\.so. This should work but requires a lot of work. Also obviously, if more things want to set %__elf_provides_exclude_path, they would need to figure out how or have a shared place to configure it.

4. Use %{_rpmconfigdir}/elfdeps --provides %{?__elf_provides_exclude_path:--exclude '%{__elf_provides_exclude_path}'} in %__elf_provides to simulate the above. However, the problem continues: If both Perl and Python want to set %__elf_provides_exclude_path to "their" path, they would need to have a shared place to configure it.

:/

[pmatilai]

This is a sub-case of the more general issue tracked now in #2922, closing.