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.)

On 03. 12. 21 21:10, Miro Hrončok 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.) For completeness, they can/should be removed by: %global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$ The list of components: hivex: libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit) iscsi-initiator-utils: libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit) libguestfs: libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit) pyliblo: liblo.cpython-310-x86_64-linux-gnu.so()(64bit) python-pandas: lib.cpython-310-x86_64-linux-gnu.so()(64bit) python-pysam: 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) 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) libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit) python3-exiv2: libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit) rb_libtorrent: libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit) uhd: libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit) Maintainers by package: hivex mdbooth rjones iscsi-initiator-utils cleech grover jwrdegoede libguestfs mdbooth rjones pyliblo fab python-pandas kushal orion sergiopr wakko666 python-pysam davidsch python3-exiv2 asn rb_libtorrent fale mooninite uhd jskarvad Packages by maintainer (BCC'ed): asn python3-exiv2 cleech iscsi-initiator-utils davidsch python-pysam fab pyliblo fale rb_libtorrent grover iscsi-initiator-utils jskarvad uhd jwrdegoede iscsi-initiator-utils kushal python-pandas mdbooth hivex libguestfs mooninite rb_libtorrent orion python-pandas rjones hivex libguestfs sergiopr python-pandas wakko666 python-pandas -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

On 03. 12. 21 22:01, Richard W.M. Jones wrote: >I don't follow this part of the original message. In, for example, >nbdkit-curl-plugin we have: > >$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so >nbdkit-curl-plugin-1.29.6-1.fc36.x86_64 >$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so | grep NEEDED > NEEDED Shared library: [libcurl.so.4] > NEEDED Shared library: [libgcc_s.so.1] > NEEDED Shared library: [libc.so.6] > >and we definitely*do* want those automatically generated >dependencies, and at the moment we get them. Yes for Requires, that would remaian the same. But we don't want to Provide nbdkit-curl-plugin.so automatically.

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.)