3554 2012-12-10 14:12:20 +0000 "all" tasks don't affect all packages? 2013-01-21 13:54:06 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.3 x86 Multiple RESOLVED NOTABUG Medium normal 1.4 1 peachj richard.purdie poky.bs.watcher poky.watcher sgw --- --- --- oldest_to_newest 28118 0 peachj 2012-12-10 14:12:20 +0000 I noticed the changes to recrdeptask from Yocto 1.2 to Yocto 1.3. I saw a number of "all" tasks in the classes change like this: -do_checkuriall[recrdeptask] = "do_checkuri" +do_checkuriall[recrdeptask] = "do_checkuriall do_checkuri" I have my own task that needs to work on all packages, and I assumed making the same change to my task would cause this to occur. (Prior to this, I had noticed the task seemed to only be running on about 12 packages, where it used to run on about 60.) So, I made the change, and indeed started running on more packages. It only ran on about 45 packages though, which I found curious. So, I dug a little deeper and had bitbake spit out pn-buildlist for me (with the -g option). That list showed around 75 packages. That meant I was still not running on a pretty large number of packages. Then I ran checkurilall. I noticed it, too, was running on the same list of packages as my task, i.e. NOT all of them. 28155 1 richard.purdie 2012-12-11 17:20:56 +0000 Its important to consider what "recrdeptask" means and there has been a bit of conflict over what exactly this means in bitbake. Taking: do_checkuriall[recrdeptask] = "do_checkuri" bitbake will look through the DEPENDS+RDEPENDS of the task and for each one, see if there is a do_checkuri task for the depedency. If it sees one, it will add a dependency on it. do_checkuriall[recrdeptask] = "do_checkuriall do_checkuri" will do the same thing but also look for and add dependencies on other do_checkuriall tasks. These in turn will have dependencies on their DEPENDS+RDEPENDS so the list is larger. This behaviour was chosen as the user can clearly select between the two different bahviours easily. Does this 100% match the previous behaviour bitbake sometimes had? No. The difference is "task dependencies" or 'tdepends'. Imagine do_something is a task after do_checkuri which has do_something[depends] = "somerecipe:do_xxx". Note that neither do_checkuri or do_checkuriall depend on this task, nor should they, it happens afterwards. Its these tasks which account for the difference you're seeing. The hard part comes if somerecipe has a do_checkuri task, should that be included in the dependecies? Right now, the answer is no, it isn't included and you can argue this both ways. The trouble is sometimes you want this behaviour and sometimes you definetely don't want it. It can trigger much more to get built than you would sometimes desire. Its also a pain to implement since you have to inject dependencies that are somewhere "up" the stack. Ultimately the solution is probably to add a new dependency type to bitbake and use this to signify when we really want *any* given task regardles of where the tdepends come in. Even then we need to carefully define the corner cases. So the current behaviour is likely intentional. It may not be the desired behaviour in every case. 28196 2 peachj 2012-12-12 16:59:56 +0000 RP, It took me a while to understand your comment, but I think I get it now. I agree with your assessment, and noticed after more careful analysis that none of the "all" tasks I care about seem to be going AWOL on packages that I care about. If you don't have any new features you want to add based on this, I guess this can be closed because everything is functioning as designed? Kind regards, Jerrod 28979 3 richard.purdie 2013-01-21 13:54:06 +0000 I'm going to close this out as the system is working as designed. If anyone has a real world use case where there are problems, we can discuss this further.