On Fri, Apr 08, 2022 at 10:18:22AM +0200, Mans Zigher wrote:
We don't have a ptest set in DISTRO_FEATURE so if that is the only way
to pull in ptest I would say that is the reason for us at least on why
there are so many bash dependencies.
One recipe that I am looking into right now is util-linux which does
have package util-linux-bash-completion but even the package
util-linux seems to depend on bash and bash-completion when
util-linux is a meta package. Install the needed util-linux utilities separately,
e.g. util-linux-mount, util-linux-umount. Also ptest you can build as distro
feature if you don't install ptest packages into images. I do that.
And then during testing, I install the ptest packages and dependencies to
the plain non-GPLv3 target to execute the tests.
checking the dependencies by running bitbake -g util-linux and bitbake
-g <image>. It is not clear why the package util-linux depends on bash
and bash-completion. I have other recipes where it is also
not obvious to me why they have a dependency to bash and
bash-completion. One such recipe is a recipe that we have created and
the only content in the package produced is a script and the script
only has #!/bin/sh so not sure where this bash and bash-completion
comes from it is not something we have added so maybe we have some
underlying issue here that results in so many dependencies to
bash and bash-completion. We have not set up this system ourselves,
instead one of the HW suppliers starting with a Q ending with COMM
which I must say I am not that impressed with has supplied the
base that we are building on.
Qualcomm, I know that one :( As integrator for a product
you must minimize the impact of the BSP SW delivery and thus allow only
bootloader, kernel and low level libraries to be compiled using the
BSP vendor delivery, e.g. their meta layers. I BBMASK away most of their
high level SW changes, e.g. systemd and other odd patches which I don't need.