You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some cases like an unfortunately named project starting with lib having a Python/Perl module, the provide may be mostly harmless if ugly. The far worse issue is bundled libraries that are incompatible with the system ones and not even in the path, but create identical provide names which a depsolver may end up pulling instead of the system level library, and break things quite badly.
The fundamental issue may well be unsolvable, the main focus here is to look for a solution that makes those bundled libraries less dangerous. If other problems get solved while we're at it, great.
The common suggestion is to filter out soname dependencies outside the system library path, but this has multiple problems: filtering them on the rpm metadata level doesn't make the dependencies go away, and they may well be needed for sub-packages and so on. What may work better is transforming the sonames dependencies for libraries outside system path to something else, perhaps including the parent package name in the name so it can't be mixed with the system or somebody elses bundled library. For provides one can do this by parsing /etc/ld.so.conf[.d] but requires seems to require solving, which is something elfdeps doesn't (and IMO, shouldn't) do. (I don't like parsing other people's config files either, but that seems unavoidable)
One simple possibility would be giving elfdeps a list/regex of soname prefixes to match. Eg, passing "libxml2" would cause it to map any dependencies found on libxml* to some other, internal-suggesting name. Such as %{name}-libxml*. That list/regex could be set by the packager, but to satisfy the goal of bundled library safety, it needs to happen automatically for provides. I guess something like this would do:
figure out system library path, considering ld.so.conf[.d] in the buildroot and everything
find out any shared libraries in the buildroot outside that path
set the elfdeps mangler (eg %{name}-) to apply to everything found in 2
profit?
Mangling discovered dependencies isn't hard, retrofitting the discovery parts to the rpm framerwork probably is.
The text was updated successfully, but these errors were encountered:
Discussed in #2872
Originally posted by pmatilai January 24, 2024
This is one of those topics that gets raised semi-annually at least. To point out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and #1227 but there are certainly more out there.
For some cases like an unfortunately named project starting with lib having a Python/Perl module, the provide may be mostly harmless if ugly. The far worse issue is bundled libraries that are incompatible with the system ones and not even in the path, but create identical provide names which a depsolver may end up pulling instead of the system level library, and break things quite badly.
The fundamental issue may well be unsolvable, the main focus here is to look for a solution that makes those bundled libraries less dangerous. If other problems get solved while we're at it, great.
The common suggestion is to filter out soname dependencies outside the system library path, but this has multiple problems: filtering them on the rpm metadata level doesn't make the dependencies go away, and they may well be needed for sub-packages and so on. What may work better is transforming the sonames dependencies for libraries outside system path to something else, perhaps including the parent package name in the name so it can't be mixed with the system or somebody elses bundled library. For provides one can do this by parsing /etc/ld.so.conf[.d] but requires seems to require solving, which is something elfdeps doesn't (and IMO, shouldn't) do. (I don't like parsing other people's config files either, but that seems unavoidable)
One simple possibility would be giving elfdeps a list/regex of soname prefixes to match. Eg, passing "libxml2" would cause it to map any dependencies found on libxml* to some other, internal-suggesting name. Such as %{name}-libxml*. That list/regex could be set by the packager, but to satisfy the goal of bundled library safety, it needs to happen automatically for provides. I guess something like this would do:
Mangling discovered dependencies isn't hard, retrofitting the discovery parts to the rpm framerwork probably is.
The text was updated successfully, but these errors were encountered: