[RFC] Proposal: New tool to display recipe dependency trees

[RFC] Proposal: New tool to display recipe dependency trees

[Osama Abdelkader]

Hi All,

I would like to propose adding a new command-line tool (or BitBake subcommand) that generates
dependency trees, including:

DEPENDS (build-time)
RDEPENDS (runtime)
Optional graph output (text, JSON)

Motivation

Currently, BitBake provides:

bitbake -g produces task-depends.dot (task-level, not recipe-level, must use graphviz)
oe-pkgdata-util runtime dependency only
bitbake -e <recipe> view variables, but manually
Errors from the dependency resolver (if a recipe is missing)

But there is no built-in CLI tool to display a recipe dependency tree, e.g.:

bitbake-deptree dnf

dnf
 ├── libdnf
 │    ├── libsolv
 │    └── json-c
 └── sqlite3


Such a tool would help:

layer developers understanding complex deps
learning how Yocto resolves recipe names, PROVIDES, virtual/ mappings
documenting or visualizing architecture

I started experimenting with a prototype using Tinfoil to walk DEPENDS and collect data through BitBake’s recipecache, and it seems feasible.

Questions for the community

Before developing this further, I would like guidance on the following:

Is this functionality valuable upstream? Would BitBake benefit from such a tool?

Where should it live?
Options I see:

new BitBake subcommand (e.g. bitbake-deptree)
extension to oe-pkgdata-util
standalone Python tool under scripts/
part of devtool?

Preferred output format(s)?
Plain ASCII tree (default)
JSON


Should the tool:

cover only DEPENDS (build-time)?
include RDEPENDS with pkgdata?
resolve virtual/ providers?

Any prior work I may have missed?

If the idea is acceptable, I will prepare a proper implementation and send a patchset to the appropriate mailing list.
Thank you for your feedback!

Best regards,
Osama

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Alexander Kanavin]

On Mon, 24 Nov 2025 at 18:24, Osama Abdelkader via
lists.openembedded.org
<osama.abdelkader=gmail.com@lists.openembedded.org> wrote:
> Should the tool:
>
> cover only DEPENDS (build-time)?
> include RDEPENDS with pkgdata?
> resolve virtual/ providers?
>
> Any prior work I may have missed?
>
> If the idea is acceptable, I will prepare a proper implementation and send a patchset to the appropriate mailing list.
> Thank you for your feedback!

Hello Osama,

DEPENDS is a somewhat unfortunate variable name that we're stuck with.

It does not actually specify a recipe dependency, it specifies
something more specific:

- run A.do_populate_sysroot before B.do_prepare_recipe_sysroot (a task
dependency)
- within B.do_prepare_recipe_sysroot task, take the output that
A.do_populate_sysroot produced and place that into B's sysroot (a hint
for sysroot creation)

So I feel that any tool that aims to make things easier should
continue to present particular tasks; there's really no such thing as
'recipe-level dependency'.

In addition to that RDEPENDS is not specifying recipes. It is
specifying packages that the recipes produce (which sometimes match
the recipe names, but are otherwise distinct). You really should not
mix them together.

I guess the question we need to ask is why 'bitbake -g' output is
difficult to understand or unhelpful in resolving questions people
have about dependencies. How can we make that better?

Alex

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Quentin Schulz]

Hi Osama,

On 11/24/25 7:04 PM, Alexander Kanavin via lists.openembedded.org wrote:
> On Mon, 24 Nov 2025 at 18:24, Osama Abdelkader via
> lists.openembedded.org
> <osama.abdelkader=gmail.com@lists.openembedded.org> wrote:
>> Should the tool:
>>
>> cover only DEPENDS (build-time)?
>> include RDEPENDS with pkgdata?
>> resolve virtual/ providers?
>>
>> Any prior work I may have missed?
>>
>> If the idea is acceptable, I will prepare a proper implementation and send a patchset to the appropriate mailing list.
>> Thank you for your feedback!
> 
> Hello Osama,
> 
> DEPENDS is a somewhat unfortunate variable name that we're stuck with.
> 
> It does not actually specify a recipe dependency, it specifies
> something more specific:
> 
> - run A.do_populate_sysroot before B.do_prepare_recipe_sysroot (a task
> dependency)
> - within B.do_prepare_recipe_sysroot task, take the output that
> A.do_populate_sysroot produced and place that into B's sysroot (a hint
> for sysroot creation)
> 
> So I feel that any tool that aims to make things easier should
> continue to present particular tasks; there's really no such thing as
> 'recipe-level dependency'.
> 
> In addition to that RDEPENDS is not specifying recipes. It is
> specifying packages that the recipes produce (which sometimes match
> the recipe names, but are otherwise distinct). You really should not
> mix them together.
> 

In addition to what Alex said, you also have RRECOMMENDS, PACKAGECONFIG, 
anonymous python functions, dynamic packaging, etc. that allow to 
specify build or runtime dependencies outside of the more common 
DEPENDS/RDEPENDS, so you'd need to interface with the internals of 
bitbake and not simply checking those variables.

Finally, there are other ways to do dependencies than those variables, 
as highlighted by Alex already. DEPENDS does A.do_populate_sysroot 
before B.do_prepare_recipe_sysroot, but you also have other ways to have 
dependencies, see the u-boot recipe for Rockchip boards here 
https://git.yoctoproject.org/meta-rockchip/tree/recipes-bsp/u-boot/u-boot-rockchip.inc. 
We depend on 1+ binary (TF-A/BL31 and OP-TEE OS/BL32) that needs to be 
available in the deploy directory before building the u-boot recipe.

Cheers,
Quentin

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Osama Abdelkader]

On Mon, Nov 24, 2025 at 07:20:52PM +0100, Quentin Schulz wrote:
> Hi Osama,
> 
> On 11/24/25 7:04 PM, Alexander Kanavin via lists.openembedded.org wrote:
> > On Mon, 24 Nov 2025 at 18:24, Osama Abdelkader via
> > lists.openembedded.org
> > <osama.abdelkader=gmail.com@lists.openembedded.org> wrote:
> > > Should the tool:
> > > 
> > > cover only DEPENDS (build-time)?
> > > include RDEPENDS with pkgdata?
> > > resolve virtual/ providers?
> > > 
> > > Any prior work I may have missed?
> > > 
> > > If the idea is acceptable, I will prepare a proper implementation and send a patchset to the appropriate mailing list.
> > > Thank you for your feedback!
> > 
> > Hello Osama,
> > 
> > DEPENDS is a somewhat unfortunate variable name that we're stuck with.
> > 
> > It does not actually specify a recipe dependency, it specifies
> > something more specific:
> > 
> > - run A.do_populate_sysroot before B.do_prepare_recipe_sysroot (a task
> > dependency)
> > - within B.do_prepare_recipe_sysroot task, take the output that
> > A.do_populate_sysroot produced and place that into B's sysroot (a hint
> > for sysroot creation)
> > 
> > So I feel that any tool that aims to make things easier should
> > continue to present particular tasks; there's really no such thing as
> > 'recipe-level dependency'.
> > 
> > In addition to that RDEPENDS is not specifying recipes. It is
> > specifying packages that the recipes produce (which sometimes match
> > the recipe names, but are otherwise distinct). You really should not
> > mix them together.
> > 
> 
> In addition to what Alex said, you also have RRECOMMENDS, PACKAGECONFIG,
> anonymous python functions, dynamic packaging, etc. that allow to specify
> build or runtime dependencies outside of the more common DEPENDS/RDEPENDS,
> so you'd need to interface with the internals of bitbake and not simply
> checking those variables.
> 
> Finally, there are other ways to do dependencies than those variables, as
> highlighted by Alex already. DEPENDS does A.do_populate_sysroot before
> B.do_prepare_recipe_sysroot, but you also have other ways to have
> dependencies, see the u-boot recipe for Rockchip boards here https://git.yoctoproject.org/meta-rockchip/tree/recipes-bsp/u-boot/u-boot-rockchip.inc.
> We depend on 1+ binary (TF-A/BL31 and OP-TEE OS/BL32) that needs to be
> available in the deploy directory before building the u-boot recipe.
> 
> Cheers,
> Quentin

Hi Quentin,

Yes, that needs to be taken into consideration too. IMHO, we need to know if 
such tool/sub-command would be helpful, or we can enhance bitbake -g, or something else
and we can go further with the details.

Thanks.

BR,
Osama

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Osama Abdelkader]

On Mon, Nov 24, 2025 at 07:04:12PM +0100, Alexander Kanavin wrote:
> On Mon, 24 Nov 2025 at 18:24, Osama Abdelkader via
> lists.openembedded.org
> <osama.abdelkader=gmail.com@lists.openembedded.org> wrote:
> > Should the tool:
> >
> > cover only DEPENDS (build-time)?
> > include RDEPENDS with pkgdata?
> > resolve virtual/ providers?
> >
> > Any prior work I may have missed?
> >
> > If the idea is acceptable, I will prepare a proper implementation and send a patchset to the appropriate mailing list.
> > Thank you for your feedback!
>

Hello Alex,
 
> Hello Osama,
> 
> DEPENDS is a somewhat unfortunate variable name that we're stuck with.
> 
> It does not actually specify a recipe dependency, it specifies
> something more specific:
> 
> - run A.do_populate_sysroot before B.do_prepare_recipe_sysroot (a task
> dependency)
> - within B.do_prepare_recipe_sysroot task, take the output that
> A.do_populate_sysroot produced and place that into B's sysroot (a hint
> for sysroot creation)

Yes, I know that.
> 
> So I feel that any tool that aims to make things easier should
> continue to present particular tasks; there's really no such thing as
> 'recipe-level dependency'.
> 
> In addition to that RDEPENDS is not specifying recipes. It is
> specifying packages that the recipes produce (which sometimes match
> the recipe names, but are otherwise distinct). You really should not
> mix them together.
> 
> I guess the question we need to ask is why 'bitbake -g' output is
> difficult to understand or unhelpful in resolving questions people
> have about dependencies. How can we make that better?

Exactly. 
For me, the output dot file usually is so large and not "human-friendly" to trace.
> 
> Alex

My motivation actually was so simple, to know why a certain package is needed in an image.
The simple way now AFAIK is to exclude it, then bitbake prints backtrace e.g.

dnf
 ├── libdnf
 │    ├── libsolv
 │    └── json-c
 └── sqlite3

dnf -> libdnf -> libsolv

libsolv is needed for dnf. so would be good to have a query command or simple tool to show that?
something like apt-rdepends output.

BR,
Osama

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Alexander Kanavin]

On Mon, 24 Nov 2025 at 19:42, Osama Abdelkader
<osama.abdelkader@gmail.com> wrote:

> My motivation actually was so simple, to know why a certain package is needed in an image.
> The simple way now AFAIK is to exclude it, then bitbake prints backtrace e.g.
>
> dnf
>  ├── libdnf
>  │    ├── libsolv
>  │    └── json-c
>  └── sqlite3
>
> dnf -> libdnf -> libsolv
>
> libsolv is needed for dnf. so would be good to have a query command or simple tool to show that?
> something like apt-rdepends output.

Yes, absolutely, and this is missing. You can deduce it from 'bitbake
-g', but it requires look at dependencies of particular tasks
(package_write_* if memory serves) and ignoring all other task
dependencies, and then making a mental dependency chain in your head
if the dependency is indirect. This could probably be post-processed
with some filtering tool to only make a tree of those dependencies,
and present it in a human friendly tree format.

One other idea is to add a task to image recipes that would produce a
tree of package dependencies. E.g. instead of making a package repo
and then constructing a root filesystem from it with a package
manager, it would use the repo to write out a tree of their
dependencies - unrolling the top level packages that the image
specifies to install. Probably it could use package managers like
dnf/apt/opkg to assist with that.

Alex

Re: [bitbake-devel] [RFC] Proposal: New tool to display recipe dependency trees

[Osama Abdelkader]

On Mon, Nov 24, 2025 at 07:53:52PM +0100, Alexander Kanavin wrote:
> On Mon, 24 Nov 2025 at 19:42, Osama Abdelkader
> <osama.abdelkader@gmail.com> wrote:
> 
> > My motivation actually was so simple, to know why a certain package is needed in an image.
> > The simple way now AFAIK is to exclude it, then bitbake prints backtrace e.g.
> >
> > dnf
> >  ├── libdnf
> >  │    ├── libsolv
> >  │    └── json-c
> >  └── sqlite3
> >
> > dnf -> libdnf -> libsolv
> >
> > libsolv is needed for dnf. so would be good to have a query command or simple tool to show that?
> > something like apt-rdepends output.
> 
> Yes, absolutely, and this is missing. You can deduce it from 'bitbake
> -g', but it requires look at dependencies of particular tasks
> (package_write_* if memory serves) and ignoring all other task
> dependencies, and then making a mental dependency chain in your head
> if the dependency is indirect. This could probably be post-processed
> with some filtering tool to only make a tree of those dependencies,
> and present it in a human friendly tree format.
> 
> One other idea is to add a task to image recipes that would produce a
> tree of package dependencies. E.g. instead of making a package repo
> and then constructing a root filesystem from it with a package
> manager, it would use the repo to write out a tree of their
> dependencies - unrolling the top level packages that the image
> specifies to install. Probably it could use package managers like
> dnf/apt/opkg to assist with that.
> 
> Alex

Thanks Alex for the feedback, I'm going to work on that soon.

BR,
Osama

Re: [yocto] [RFC] Proposal: New tool to display recipe dependency trees

[Ross Burton]

On 24 Nov 2025, at 17:24, Osama Abdelkader via lists.yoctoproject.org <osama.abdelkader=gmail.com@lists.yoctoproject.org> wrote:
> 
> Hi All,
> 
> I would like to propose adding a new command-line tool (or BitBake subcommand) that generates
> dependency trees, including:
> 
> DEPENDS (build-time)
> RDEPENDS (runtime)
> Optional graph output (text, JSON)
> 
> Motivation
> 
> Currently, BitBake provides:
> 
> bitbake -g produces task-depends.dot (task-level, not recipe-level, must use graphviz)
> oe-pkgdata-util runtime dependency only
> bitbake -e <recipe> view variables, but manually
> Errors from the dependency resolver (if a recipe is missing)
> 
> But there is no built-in CLI tool to display a recipe dependency tree, e.g.:
> 
> bitbake-deptree dnf
> 
> dnf
> ├── libdnf
> │    ├── libsolv
> │    └── json-c
> └── sqlite3
> 
Note that the build-time and run-time dependency trees will be a _lot_ deeper than that.

The ability to mark some dependencies as “soft roots” (eg gcc-cross, glibc) and optionally stop at them would be useful.

> Is this functionality valuable upstream? Would BitBake benefit from such a tool?

Yes

> Where should it live?
> Options I see:
> 
> new BitBake subcommand (e.g. bitbake-deptree)
> extension to oe-pkgdata-util
> standalone Python tool under scripts/
> part of devtool?

I’d say this is a question for later, the question for now is “make it work”.

> Preferred output format(s)?
> Plain ASCII tree (default)
> JSON

And HTML/SVG graphs.

> Should the tool:
> 
> cover only DEPENDS (build-time)?
> include RDEPENDS with pkgdata?
> resolve virtual/ providers?

Yes to all.

> Any prior work I may have missed?

bitbake’s own taskexp (bitbake -g taskexp) is basically this with more granularity (because it’s task dependencies, not recipe) and without the drawing of an actual tree (partly because I just implemented it as a three pane window for convenience.

oe-pkgdata-browser (oe-core/scripts) and pkgexp (https://gitlab.com/rossburton/pkgexp) let you dig around the pkgdata interactively.

bitbake-whatdepends does basic processing on the dot file output from bitbake to let you see _why_ recipe A depends on recipe B.

Many people ask for this tool, so I hope you manage to implement something that works well.  I’ve started a few times, but never finished…

Ross

Re: [yocto] [RFC] Proposal: New tool to display recipe dependency trees

[Osama Abdelkader]

On Mon, Nov 24, 2025 at 08:49:31PM +0000, Ross Burton wrote:
> On 24 Nov 2025, at 17:24, Osama Abdelkader via lists.yoctoproject.org <osama.abdelkader=gmail.com@lists.yoctoproject.org> wrote:
> > 
> > Hi All,
> > 
> > I would like to propose adding a new command-line tool (or BitBake subcommand) that generates
> > dependency trees, including:
> > 
> > DEPENDS (build-time)
> > RDEPENDS (runtime)
> > Optional graph output (text, JSON)
> > 
> > Motivation
> > 
> > Currently, BitBake provides:
> > 
> > bitbake -g produces task-depends.dot (task-level, not recipe-level, must use graphviz)
> > oe-pkgdata-util runtime dependency only
> > bitbake -e <recipe> view variables, but manually
> > Errors from the dependency resolver (if a recipe is missing)
> > 
> > But there is no built-in CLI tool to display a recipe dependency tree, e.g.:
> > 
> > bitbake-deptree dnf
> > 
> > dnf
> > ├── libdnf
> > │    ├── libsolv
> > │    └── json-c
> > └── sqlite3
> > 
> Note that the build-time and run-time dependency trees will be a _lot_ deeper than that.
> 
> The ability to mark some dependencies as “soft roots” (eg gcc-cross, glibc) and optionally stop at them would be useful.
> 
> > Is this functionality valuable upstream? Would BitBake benefit from such a tool?
> 
> Yes
> 
> > Where should it live?
> > Options I see:
> > 
> > new BitBake subcommand (e.g. bitbake-deptree)
> > extension to oe-pkgdata-util
> > standalone Python tool under scripts/
> > part of devtool?
> 
> I’d say this is a question for later, the question for now is “make it work”.
> 
> > Preferred output format(s)?
> > Plain ASCII tree (default)
> > JSON
> 
> And HTML/SVG graphs.
> 
> > Should the tool:
> > 
> > cover only DEPENDS (build-time)?
> > include RDEPENDS with pkgdata?
> > resolve virtual/ providers?
> 
> Yes to all.
> 
> > Any prior work I may have missed?
> 
> bitbake’s own taskexp (bitbake -g taskexp) is basically this with more granularity (because it’s task dependencies, not recipe) and without the drawing of an actual tree (partly because I just implemented it as a three pane window for convenience.
> 
> oe-pkgdata-browser (oe-core/scripts) and pkgexp (https://gitlab.com/rossburton/pkgexp) let you dig around the pkgdata interactively.
> 
> bitbake-whatdepends does basic processing on the dot file output from bitbake to let you see _why_ recipe A depends on recipe B.
> 
> Many people ask for this tool, so I hope you manage to implement something that works well.  I’ve started a few times, but never finished…
> 
> Ross

Thanks Ross, this is very helpful, I'm going to look at that and start the implementation soon.
Will need your feedback for sure, but as you said, let's make it work first then we discuss further details in the patchset thread.

BR,
Osama