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!