| Summary: | print which pkgs would be built | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Robert Yang <liezhi.yang> |
| Component: | bitbake | Assignee: | Robert Yang <liezhi.yang> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | bluelightning, jason.wessel, mark.hatle, poky.bs.watcher, poky.watcher, richard.purdie, sgw, song.liu, yi.zhao, zhenfeng.zhao |
| Version: | 1.3 | ||
| Target Milestone: | 1.3 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| See Also: | https://bugzilla.yoctoproject.org/show_bug.cgi?id=2406 | ||
| Whiteboard: | (P2)(QA Testing Completed)(Done) | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Robert Yang
2012-05-03 08:18:54 UTC
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 .... |