Re: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 3, 2021 at 3:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux