4349 2013-04-19 08:56:36 +0000 An easy way to find out why a recipe is built and installed (RDEPENDS) 2018-03-30 18:41:29 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.5 x86 Multiple RESOLVED FIXED https://bugzilla.yoctoproject.org/show_bug.cgi?id=4352 Medium enhancement 2.5 1 liezhi.yang ross.burton bluelightning corneliux.stoicescu Jc kergoth mark.hatle poky.bs.watcher poky.watcher randy.macleod richard.purdie sgw srifenbark --- --- Yes (doc changes required) oldest_to_newest 32378 0 liezhi.yang 2013-04-19 08:56:36 +0000 The "bitbake -g" can generate pn-depends.dot and package-depends.dot, the advanced user can find out why a package is built (DEPENDS) and installed (RDEPENDS) from the two dot files, but it's not easy for a new user, maybe we can add an option like: bitbake -w/--why <recipe> <image> which will show the DEPENDS and RDPENDS of <recipe> for the <image>, e.g.: bitbake -w curl core-image-sato Or we can add a single python script bitbake-why in bitbake/bin/ 32379 1 liezhi.yang 2013-04-19 08:59:13 +0000 And such a function would make the user easy to remove a recipe/package which he doesn't need from the image. 32384 2 bluelightning 2013-04-19 11:03:09 +0000 This would be very useful, we get asked how to find this information a lot. I guess it would show the whole dependency chain that resulted in the recipe being built. It would also need to handle dependencies at the task level (less likely than DEPENDS or RDEPENDS but it does occur). I wonder if this ought to be part of the "bb" tool which I think we should be looking at integrating ( https://github.com/kergoth/bb ) 32882 3 kergoth 2013-05-03 23:49:57 +0000 (In reply to comment #2) > This would be very useful, we get asked how to find this information a lot. > I guess it would show the whole dependency chain that resulted in the recipe > being built. It would also need to handle dependencies at the task level > (less likely than DEPENDS or RDEPENDS but it does occur). > > I wonder if this ought to be part of the "bb" tool which I think we should > be looking at integrating ( https://github.com/kergoth/bb ) The existing 'whatdepends' subcommand shows what pulled something in, recursively, but currently only checks DEPENDS/PROVIDES, not runtime. My next task once I manage to find the time to look at this tool again will be to add full fledged handling of multiple types of dependency, with display of which one pulled it in. Example of current whatdepends behavior: $ bb whatdepends -r attr core-image-minimal Parsing recipes..done. acl libcap avahi libgcrypt gtk+ libglade Example of the sort of all-types-of-dependency information I want to add to it, as an example of my previous 'dependinfo' command, which did the opposite (showed what something depended on, not what depends on it) non-recursively: https://gist.github.com/kergoth/4455568 32908 4 liezhi.yang 2013-05-07 09:38:56 +0000 (In reply to comment #3) > (In reply to comment #2) > > This would be very useful, we get asked how to find this information a lot. > > I guess it would show the whole dependency chain that resulted in the recipe > > being built. It would also need to handle dependencies at the task level > > (less likely than DEPENDS or RDEPENDS but it does occur). > > > > I wonder if this ought to be part of the "bb" tool which I think we should > > be looking at integrating ( https://github.com/kergoth/bb ) > > The existing 'whatdepends' subcommand shows what pulled something in, > recursively, but currently only checks DEPENDS/PROVIDES, not runtime. My > next task once I manage to find the time to look at this tool again will be > to add full fledged handling of multiple types of dependency, with display > of which one pulled it in. > > Example of current whatdepends behavior: > > $ bb whatdepends -r attr core-image-minimal > Parsing recipes..done. > acl > libcap > avahi > libgcrypt > gtk+ > libglade > > Example of the sort of all-types-of-dependency information I want to add to > it, as an example of my previous 'dependinfo' command, which did the > opposite (showed what something depended on, not what depends on it) > non-recursively: https://gist.github.com/kergoth/4455568 Great, I've tried it and it worked well, I think this is what we are looking for if it can check the RDEPENDS, is there anything I can do ? Do we plan to add it to yocto 1.5 ? 32916 5 kergoth 2013-05-07 13:57:51 +0000 If you check the yocto 1.5 features page on the wiki, you'll see that there's an entry for improving bitbake's UI along these lines. Whether it will take this form, I don't know, Richard and I often disagree about implementation, but something like this should be in the cards for 1.5. 32938 6 richard.purdie 2013-05-08 09:16:07 +0000 Robert asked me to comment. I agree with integrating something like this, the exact form just needs to be determined. I'm not 100% sure exactly what makes sense at this point but I agree with the idea in principle. 34449 7 liezhi.yang 2013-07-10 06:09:51 +0000 I've tried to let the bb tool figure out which packages will be installed according to the RDEPENDS and RRECOMMENDS, but it is far away from the packages that are really installed: For a core-image-sato: 1) the bb figures out 198 packages will be installed 2) but 387 packages are installed 3) For the 198 packages, 61 ones are not in the 387 ones So I failed to figure out the one which would be installed, the problem is that the binary package (e.g., rpm) will have more depends info than RDEPENDS and RRECOMMENDS according the file dependcies. I'd like to not add the RDEPENDS at the moment, it is still very useful for us though it doesn't support the RDEPENDS, for example, the "bb whatdepends", "bb edit", "bb log" and so on will help the end user a lot. I think that what can we do next are: 1) Add the bb tool to yocto, I think that we can put it to poky/scripts/bb or poky/bitbake/contrib/ 2) When we decide to add it to yocto, will we add all the source at one time ? Or we will add the commit one by one ? There are 80 commits. 34450 8 liezhi.yang 2013-07-10 06:27:26 +0000 Here is the draft patch, note, it is very rough: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=robert/bb_rdepends_draft&id=e8561d22d00125889c674e353f377ce86abdfdaf 36061 9 liezhi.yang 2013-08-30 01:45:44 +0000 Move to 1.6 after talked with Saul and RP. 37304 10 Jc 2013-09-27 21:03:59 +0000 Well I did it with your patch but had missed the comment about entering one repo per directory. I added them and now the flow is ok. I need to rebuild an image without curl to check if the dependency issue is solved or not... 51402 11 srifenbark 2015-06-01 21:44:57 +0000 Hi, Not sure about the activity here on this bug. I noted that we do have a 'bitbake -w' command at the moment but it is for writing an event log. If we do create some option to address this issue, it will definitely affect the BB user manual. I am noting this here to be sure I see it. Scott 76841 12 ross.burton 2017-09-14 15:15:17 +0000 taskexp is probably the best we have for this, although I think bb had a command which would show you the path between two recipes and can be used to see why a recipe is built for an image. 79773 13 ross.burton 2018-03-09 04:00:50 +0000 I'd say that oe-depends-dot (oe-core 7dc7860691304d63e7ad728d2180474906fe0a5c) is a good move towards this, closing. 80052 14 srifenbark 2018-03-30 18:41:29 +0000 Ross, Does this affect the BB manual at all? Scott