这是一个老问题，我知道
Yocto: why is a package included?
Why is package included in Yocto rootfs?
但没有满意的答案。
我在 yocto 自定义图像中得到 valgrind（用任何包名称替换 valgrind），但我不知道为什么。
Valgrin 的配方 RDEPENDS 变量显示将在映像中安装哪些包以供 valgrind 运行。
有没有办法知道反向功能？也就是说，他的 RDEPENDS valgrind 中有什么配方？
bitbake -g valgrind 或在配方文件中查找 valgrind 没有帮助。
【问题讨论】：
有几种方法可以找到它：
bitbake -g 可能是其中之一，您只是错误地设置了目标。
bitbake -g 获取 BUILD 依赖项，因此，它会告诉您需要构建 valgrind 的包（或任务），但是执行 bitbake -g valgrind 会告诉您 valgrind 需要哪些 包，不是什么包需要valgrind（不一样），你需要做的：
bitbake <your-image> -g
例如
bitbake core-image-minimal -g
这将是您图像的构建依赖项，它可能会告诉您图像中的哪个包需要 valgrind，（打开 task-depends.dot 文件并查找右侧的 valgrind 行）
如果 bitbake -g 不够用，Bitbake -e 可能是另一种方式
bitbake -e | grep PACKAGE_INSTALL
bitbake -e 将打印出 bitbake 的字典，特别是您应该查看 PACKAGE_INSTALL 变量，如果 valgrind 存在，您可以看到将它添加到变量的配方以及安装它的原因
如果valgrind实际上是一个二级依赖，也就是说PACKAGE_A有一个RDEPENDS+="valgrind"，并且需要安装PACKAGE_A，那么你需要查看包管理器的输出，这取决于你是否正在使用 RPM、DEB 或 IPK 文件，有更具体的方法可以找到它，但查看图像的 log.do_rootfs 文件可能会为您提供足够的信息，了解哪个包对 valgrind 具有运行时依赖项：
例如，如果您使用 RPM，您会看到类似这样的内容（为便于阅读而修剪）：
$ cat tmp/work/qemuarm64-poky-linux-musl/core-image-minimal/1.0-r0/temp/log.do_rootfs
Package Arch Version Repo Size
================================================================================
Installing:
base-passwd cortexa57 3.5.29-r0 oe-repo 7.2 k
busybox cortexa57 1.35.0-r0 oe-repo 364 k
busybox-mdev cortexa57 1.35.0-r0 oe-repo 8.7 k
dropbear cortexa57 2020.81-r0 oe-repo 132 k
initramfs-live-boot-tiny qemuarm64 1.0-r12 oe-repo 8.6 k
packagegroup-core-boot qemuarm64 1.0-r17 oe-repo 5.8 k
run-postinsts noarch 1.0-r10 oe-repo 7.4 k
Installing dependencies:
base-files qemuarm64 3.0.14-r89 oe-repo 13 k
busybox-inittab qemuarm64 1.35.0-r0 oe-repo 7.6 k
eudev cortexa57 3.2.10-r0 oe-repo 181 k
libblkid1 cortexa57 2.37.3-r0 oe-repo 85 k
libkmod2 cortexa57 29-r0 oe-repo 36 k
libz1 cortexa57 1.2.11-r0 oe-repo 46 k
musl cortexa57 1.2.2+git0+c4d4028dde-r0 oe-repo 364 k
netbase noarch 1:6.3-r0 oe-repo 14 k
update-alternatives-opkg cortexa57 0.5.0-r0 oe-repo 8.5 k
Installing weak dependencies:
busybox-syslog cortexa57 1.35.0-r0 oe-repo 8.7 k
在此示例中，您可以看到我从未请求将libz1 安装在我的映像中（以及其他列为依赖项的），但是上面部分中的一个包需要这些包才能运行。
log.do_rootfs 文件中有更多信息可以直接告诉您需要什么 valgrind，如果您仍然找不到它，请返回 bitbake -g 并查找包含上述软件包的行（因为这些直接依赖于您的图像)，其中之一应该需要 valgrind。
RPM 命令
最后但同样重要的是，这是为 rpms 量身定制的，但是对于 debs 或 ipks 的过程应该非常相似，尽管命令会有所不同，但是一旦您从 log.do_rootfs 获得要安装的软件包列表，您就可以查询通过 rpm 命令获取 rpm 包：
我将使用 dropbear 包作为上面的示例：
$ rpm -qR tmp/deploy/rpm/cortexa57/dropbear-2020.81-r0.cortexa57.rpm
/bin/sh
libc.so()(64bit)
libz1 >= 1.2.11
libz.so.1()(64bit)
rtld(GNU_HASH)
update-alternatives-opkg
所以，就我而言，dropbear 包是 libz1 依赖的罪魁祸首。
【讨论】：
感谢您的回答@aehs29，很有启发性，但是有很多包已构建但未安装。
我不明白 bitbake -g <image-recipe> 告诉我 build 依赖项，而不是 runtime 依赖项，是的，我的自定义映像具有来自 valgrind 的构建依赖项但我无法在 task-depends.dot 文件中获得有关谁是有罪的信息。
valgrind 没有在bitbake -e | grep PACKAGE_INSTALL 中列出，所以运气不好。
我正在使用 ipkg 包，所以 log.do_rootfs 文件不显示包依赖关系表。
查看包文件是不可行的，因为有许多未安装的包具有 valgrind 依赖项。
策略是首先构建映像，然后删除 valgrind 配方，再次尝试构建映像并分析错误。
user@build:~/home/user/yocto-local/build$ bitbake mycustom-image
Loading cache: 100% |######################| Time: 0:00:01
Loaded 4841 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'valgrind' (but /home/user/yocto-local/sources/meta-imx/meta-bsp/recipes-graphics/imx-gpu-viv/imx-gpu-viv_6.4.3.p2.2-aarch64.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'valgrind' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['valgrind']
NOTE: Runtime target 'opencv' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['opencv', 'virtual/opencl-icd', 'valgrind']
ERROR: Required build target 'mycustom-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['mycustom-image', 'opencv', 'virtual/opencl-icd', 'valgrind']
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
我相信这不是一种“正式”的做法，但我还没有找到另一种做法。
【讨论】：