Skip to content

Do not scan .so files in %{_libdir} on EL9

Whenever the isc-bind-libevent RPM package is present in epel-9-x86_64 Copr chroot, the creation of bootstrap chroot for any isc-bind-* package fails with:

Start(bootstrap): dnf install
...
Installing:
 dnf                                      noarch  4.12.0-4.el9              baseos     468 k
 dnf-plugins-core                         noarch  4.1.0-3.el9               baseos      38 k
 subscription-manager                     x86_64  1.29.30-1.el9             baseos     903 k
...
Installing dependencies:
...
 isc-bind-libevent                        x86_64  2.1.12-4.el9              copr_base  261 k
...
Start: dnf install
Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.9/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python3.9/site-packages/libdnf/__init__.py", line 12, in <module>
    from . import conf
  File "/usr/lib64/python3.9/site-packages/libdnf/conf.py", line 13, in <module>
    from . import _conf
ImportError: libevent-2.1.so.7: cannot open shared object file: No such file or directory
WARNING: Dnf command failed, retrying, attempt #2, sleeping 10s

The immediate reason is that the isc-bind-libevent package was picked by dependency solving process instead of the stock libevent package. Therefore, e.g., dnf or curl packages have satisfied RPM dependencies, but their binaries, like curl, which require libevent-2.1.so.7 fail to find the library as only /opt/isc/isc-bind/root/usr/lib64/libevent-2.1.so.7 is present in the system.

The reason for this undesirable behavior is that the isc-bind-libevent package is just an SCL-enabled clone of the stock Fedora libevent package and, from the point of view of the dependency-solving process, interchangeable. The SCL Packaging Guide, section 3.5.3., anticipated this problem and suggested: "use the %__provides_exclude_from macro to prevent scanning certain files for automatically generated RPM symbols".

The issue is unlikely to be seen by isc-bind end-users as the libevent package is nearly always present before isc-bind-libevent gets installed because omnipresent tools like dnf and curl tend to be installed on the system from the start. For the most part, only chroot-like environments installed from "nothing" get affected.


But not always... I was able to build all isc-bind-* packages in my bind repo fork. I don't know if this is the reason, but I started the build process by completely removing all builds from the repo, making it empty. Then even when I build isc-bind-libevent on epel-9-x86_64, it never failed building of any other isc-bind-* packages as it used to (see above).

I suggest we consider this change only if we spot the ImportError: libevent-2.1.so.7: cannot open shared object file error when rebuilding actual ISC Coprs.

Merge request reports