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.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
