Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safer handling of internal soname dependencies #2922

Open
pmatilai opened this issue Feb 21, 2024 Discussed in #2872 · 0 comments
Open

Safer handling of internal soname dependencies #2922

pmatilai opened this issue Feb 21, 2024 Discussed in #2872 · 0 comments
Labels
generator Dependency generation related handsfree Packaging automation and convenience

Comments

@pmatilai
Copy link
Member

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:

  1. figure out system library path, considering ld.so.conf[.d] in the buildroot and everything
  2. find out any shared libraries in the buildroot outside that path
  3. set the elfdeps mangler (eg %{name}-) to apply to everything found in 2
  4. profit?

Mangling discovered dependencies isn't hard, retrofitting the discovery parts to the rpm framerwork probably is.

@pmatilai pmatilai added generator Dependency generation related handsfree Packaging automation and convenience labels Feb 21, 2024
@pmatilai pmatilai added this to RPM Feb 21, 2024
@github-project-automation github-project-automation bot moved this to Backlog in RPM Feb 21, 2024
@pmatilai pmatilai moved this from Backlog to Priority in RPM Feb 21, 2024
@pmatilai pmatilai moved this from Priority to Todo in RPM Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generator Dependency generation related handsfree Packaging automation and convenience
Projects
Status: Todo
Development

No branches or pull requests

1 participant