On Fri, Dec 03, 2021 at 09:23:39PM +0100, Miro Hrončok wrote:
> 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 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.
> >>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)
However these Python ones do seem like they could be wrong, but I'm
not sure if they are harmful.
What's bad about these?
Rich.
> >(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
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
_______________________________________________
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
