On Fri, Dec 3, 2021 at 3:10 PM Miro Hrončok <mhron...@redhat.com> wrote: > > On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote: > > We had an incident today [1] that opae-devel has auto-generated provides > > like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl > > (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so). > > It was pulled into the buildroot instead of the expected openssl1.1 package. > > Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in > > /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the > > file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'. > > > > My question: shouldn't we limit the elfdeps generator to files which > > are in paths that can be loaded automatically by the linker? (This > > could be implemented as e.g. the paths that are default like > > /usr/lib64, /usr/local/lib64, …, depending on the architecture, and if > > the package installs anything in /etc/ld.so/, also the paths listed there.) > > > > I always understood those Provides/Requires to be used for library > > dependency resolution, and it doesn't seem to make sense to generate > > them for plugins and other "private" objects outside of the linker > > load paths. > > > > I think it's much much more common to have .so libraries outside of > > the linker paths for which we don't want the automatic provides > > (python modules, java extensions, various loadable plugins), than to > > have shared libraries in some custom directory. This should eliminate > > most of the stupid issues where a "private" dependency leaks and > > breaks other packages. > > > > [1] bugzilla.redhat.com/2028852 > > As one of the Fedora's Python maintainers, I fully support the idea of only > generating provides from "normal" library directories. > > We still have Python packages that accidentally provide stuff like: > > lib.cpython-310-x86_64-linux-gnu.so()(64bit) > libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit) > libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit) > libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit) > libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit) > libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit) > libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit) > libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit) > libctabix.cpython-310-x86_64-linux-gnu.so()(64bit) > libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit) > libcutils.cpython-310-x86_64-linux-gnu.so()(64bit) > libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit) > libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit) > libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit) > libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit) > libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit) > liblo.cpython-310-x86_64-linux-gnu.so()(64bit) > libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit) > libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit) > > (This is actually from Fedora Rawhide, as of today.) >
The issue is self-Requires. Because the RPM dependency generator doesn't cancel out self-Requires, filtering out Provides leads to broken Requires in a lot of cases. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
