<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jan 11, 2016 at 5:57 AM Ahsan, Noor <<a href="mailto:Noor_Ahsan@mentor.com">Noor_Ahsan@mentor.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="color:black">I noticed one thing that when we add dev-pkg in IMAGE_FEATURE variable it not only install the dev package of corresponding target packages present in rootfs rather it also brings in extra target packages. I investigated
it and I found that the reason of inclusion of extra target packages I rootfs is due to dependency of a dev package on dev package of packages present in DEPENDS. In order to make it clear let’s take example of readline recipe. It is dependent on ncurses.
If we analyze ipk file of readline-dev package we will see that it ipk is Recommending ncurses-dev package</span></p>
<p class="MsoNormal"><span style="color:black">Recommends: libc6-dev, libgcc-s-dev, ncurses-libtinfo-dev, ncurses-dev</span><span style="color:black"> </span></p>
<p class="MsoNormal"><span style="color:black">So when readline-dev will be installed in rootfs it will also install ncurses-dev. Now analyze ncurses-dev ipk, it will show that it is dependent on ncurses main package</span></p>
<p class="MsoNormal"><span style="color:black">Depends: libtinfo5, ncurses (= 5.9-r15.1.6), libpanelw5, libform5, libtic5, libmenuw5, libformw5, libpanel5, libmenu5, libticw5</span></p>
<p class="MsoNormal"><span style="color:black">So ncurses main package is installed indirectly if we install readline-dev.</span></p>
<p class="MsoNormal"><span style="color:black">I thought that we should discuss this in community so that we can comeup with common decision.</span></p></div></div></blockquote><div><br></div><div>I'm moving this thread to openembedded-architecture, as changing anything related to depchains could have high impact. I've opened an issue in the BTS about this, hopefully with some info that better clarifies the issue. I'm not certain whether this is something we should even try to address, which is why I'm bringing this thread back to the surface, so we can determine this.<br><br>From the bug (forgive the wall of text, I'm including it here for ease of replying).:</div><div><br></div><div>Currently, we don't distinguish between the dependencies needed to build a project (i.e. ncurses) and those needed to develop against that project. For example, there could be many deps needed to build ncurses which aren't needed to link against it.</div><div><br></div><div>Let's say we alter RDEPENDS_${PN}-dev to dep on a lib sub-package rather than the main package, so as to avoid pulling in a ton of tools and whatnot that aren't needed for development, but then depchains pulls in everything in DEPENDS anyway, along with every rdep of every sub-package, rather than only traversing the rdeps listed in RDEPENDS_${PN}-dev. This limits our ability to control what's really needed to develop for a project, unless we disable depchains entirely.
</div><div><br></div><div>It'd be nice to have an option to just add rrecs on the recipe dev packages for any binary packages my -dev depends on. Also, pkg_addrrecs isn't ideal, it blindly adds -dev to runtime dependencies, even though -dev is recipe-wide. Since we're running at do_package-time, we should be able to use pkgdata to map the rdeps back to the recipes and add -dev to those, so my hypothetical case could have RDEPENDS_${PN}-dev pull in ${PN}-lib, and then RDEPENDS_${PN}-lib mapped back to the recipes providing those packages, and dep on the ${PN}-dev of those recipes.</div><div><br></div><div>1. Enhance the rdep handling to map back to recipes</div><div>2. Consider changing the default behavior, or at least add options to control the default behavior, of package_depchains, to allow us to limit the scope to what's really needed to develop. Either that, or anyone who cares can start manually populating RRECOMMENDS_${PN}-dev :)</div><div><br></div><div>This originated with noticing that installing dev-pkgs installed more than just -dev packages, it also sucked in a ton of sub-packages from both the requested packages and their deps, so a lot of tools and whatnot get installed which aren't needed for development at all.
<br><br>I'm a bit torn on this one. Err'ing on the side of including everything makes a certain amount of sense, to avoid risk of having a non-functional development environment, and an argument could be made that anyone doing on-target development shouldn't care about size. On the other hand, this bloats up our SDK/ADT/etc by sucking everything into the sysroot, so limiting the scope somewhat, while keeping the core of the functionality, could make a certain amount of sense. I think it could be worth experimenting with removing the DEPENDS bits, but keeping the RDEPENDS-for-all-binary-packages bits.<br><br>Further commented:<br><br>I'm thinking *if* this is worth looking into at all, it could be worth trying a prototype of:
1. make the rdep handling map back to recipe names rather than adding -dev to runtime deps, to make it more fully featured
2. make RDEPENDS_${PN}-dev default to including every emitted binary package, not just ${PN}, then the user could pare that down if they choose to
3. limit the scope from the current 'rdeps of every binary package' to 'rdeps of every package listed in RDEPENDS_${PN}-dev'
4. remove DEPENDS handling, keeping just the now-more-capable-RDEPENDS-handling
5. add some automatic rdeps to -dev, i.e. if it ships a .pc, rdep on pkg-config, that should fill in the gaps a bit for the bits lost by dropping DEPENDS<br><br></div><div>Any thoughts?</div></div></div>