Yocto: How to know why a package is included?

Question

This is a old question, I know

Yocto: why is a package included?

Why is package included in Yocto rootfs?

but there is not satisfactory answer.

I get valgrind inside my yocto custom image (sustitute valgrind with whatever package name) and I do not why.

Valgrin's recipe RDEPENDS variable show what packages will be installed in the image for valgrind runs.

Is there any way to know the reverse function? that is, what recipe has in his RDEPENDS valgrind?

bitbake -g valgrind or find valgrind in recipes files do not help.

Answer 1

There's several ways to find this out: bitbake -g may be one of them, you are just setting the target incorrectly. bitbake -g gets the BUILD dependencies, so, it tells you what package (or task) required valgrind to be built, however doing bitbake -g valgrind will tell you what packages are required for valgrind, not what packages require valgrind (not the same), you need to do: bitbake <your-image> -g e.g. bitbake core-image-minimal -g This will the the build dependencies for your image, and it may tell you what package from your image required valgrind, (open the task-depends.dot file and look for the valgrind lines on the right)

Bitbake -e may be another way if bitbake -g didnt suffice

bitbake -e | grep PACKAGE_INSTALL

bitbake -e will print out bitbake's dictionary, and specifically you should be looking at the PACKAGE_INSTALL variable, if valgrind is there, you can see what recipe added it to the variable and hence why its being installed

If valgrind is actually a secondary dependency, that is to say PACKAGE_A has an RDEPENDS+="valgrind", and PACKAGE_A is required to be installed, then you need to look at the package manager output, this varies depending if you are using RPMs, DEBs or IPKs files, there's more specific ways to find this out but looking at the log.do_rootfs file for your image would probably give you enough information about which package had a runtime dependency to valgrind:

for example if you used RPMs you would see something like this (trimmed for easier reading):

$ 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

In this example, you can see that I never requested libz1 to be installed in my image (and others listed as dependencies), however one of the packages from the upper section required those to run. There's much more information in the log.do_rootfs file which may directly tell you what required valgrind, if you still cant find it, go back to bitbake -g and look for the lines containing the packages above (since those are direct dependencies to your image), one of them should be requiring valgrind.

The RPM command

Last but not least, this is tailored for rpms, but the process should be fairly similar for debs or ipks, although the commands will differ, but once you have the list of packages to be installed from log.do_rootfs you can query the rpm packages via the rpm command:

I'll use the dropbear package as an example from above:

$ 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

So, in my case, the dropbear package is the one to blame for the libz1 dependency.