It would be great if bitbake can tell the user which pkgs would be built and installed to target rootfs. For example, when "bitbake core-image-sato", there are many pkgs (native and target) would be built, and a part of them would be installed to the target rootfs, it would be great if we can get such a list before the build. Maybe we can add an option to bitbake to do this, something like: bitbake --list-pkgs core-image-sato which would print the pkgs that would be built.
How do you pln to predict what the package manager is going to install? Bitbake has no knowledge to work this out from so you'd have to break API separation to even try and get the information. Even if you do, the list is going to be inaccurate and I don't want to give the user inaccurate information. I'm therefore worried this task isn't realistically possible.
(In reply to comment #1) > How do you pln to predict what the package manager is going to install? > Thanks, let's give up the "install" stage, is it possible to predict which recipe is going to build, please ? > Bitbake has no knowledge to work this out from so you'd have to break API > separation to even try and get the information. Even if you do, the list is > going to be inaccurate and I don't want to give the user inaccurate > information. > > I'm therefore worried this task isn't realistically possible.
Won't bitbake -n provide what you want for that, it provides a list of all the tasks, not just the recipes.
(In reply to comment #3) > Won't bitbake -n provide what you want for that, it provides a list of all > the tasks, not just the recipes. I'm afraid not, what we need is to let the user see which pkg would be built clearly.
I believe the request is that given a task, what runtime packages are going to be built. (I realize that we can't be 100% certain due to some of the dynamic package generation capabilities in Bitbake...) This would then give someone an idea in the end what will be built/available for install by the image system. (I agree, we can't determine what will be installed into the image by the package manager until they are built, because we're lacking the necessary runtime information.)
This is for giving the user a clear list to show which pkg would be built, we have the "bitbake -g", but it is not easy to read currently, it is for "dot". I think that we can improve the "bitbake -g" to achieve this, here is the draft design document: Modify the current "bitbake -g" to make it *also* print a clear pkg name list that would be built, and save it to pn-buildlist, for example: $ bitbake -g gzip Then the pn-buildlist would be: acl-native attr-native autoconf-native automake-native bash binutils-cross binutils-native bison-native bzip2-native curl-native db [snip]
merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=041a0e8dff1daf333613f3dd06a9bfc218213462
Verified with 1.3 m2 rc1. git info: eb0cb7e8234f5d2e5623406e9660be91cf52f65e Run "bitbak -g core-image-sato-sdk", $cat pn-buildlist busybox shadow-native pth sysfsutils qemu-helper-native curl-native ncurses-native gdbm binutils-cross xserver-xorg ... ... Run "bitbak -g gzip", $cat pn-buildlist libtool-cross zlib m4-native eglibc-initial prelink-native ncurses-native readline-native eglibc apr-util-native gnu-config-native gettext pseudo-native binutils-native gdbm perl attr-native ....