Optimization of Dependency Retrieval for Red Hat-Based Systems

Currently, Syft retrieves dependencies for Red Hat-based systems by scanning the system's rpmdb metadata files, recording the Requires and Provides fields of each package in the system. Dependencies are determined by matching the Requires of a package with the Provides of others. If multiple providers exist for the same Require, the current logic in Syft records all of them. However, in practice, the system only uses one of these providers for the given Require.

For example, many software packages include a dependency on /bin/sh, but there are two possible providers for /bin/sh: coreutils and bash. When generating an SBOM for an openEuler 24.03 (LTS) container with Syft, it was observed that the info@7.0.3-3.oe2403 package lists bash, coreutils, glibc, and ncurses-libs as its dependencies. Upon analyzing why Syft detected these four dependencies, it became clear that:

Both coreutils and bash are providers for /bin/sh.

Thus, both coreutils and bash were recorded as dependencies. However, in actual usage, the provider for /bin/sh is the bash package. This raises the question of whether it is necessary to include coreutils as a dependency of the info package when it does not provide /bin/sh in the context of actual system use.
To improve accuracy, it is suggested to use the rpm -q --whatprovides XXX command to precisely identify which provider is actually being used by the system for a specific dependency. This would enhance the reliability of the dependency relationship retrieval process and prevent the inclusion of unnecessary packages in the SBOM.

Below is a screenshot of the metadata I took from rpmdb:

Start by tracing Syft's Red Hat rpmdb dependency retrieval and the logic that matches package Requires fields to Provides fields. Compare that flow with the reported `rpm -q --whatprovides` behavior for `/bin/sh`; done means dependency relationships select the provider actually used rather than recording every possible provider, with coverage for the reported openEuler case.

Written by the indexing model from the issue text.