[Openembedded-architecture] [OE-core] some dev pkg bring extra target packages when installed in rootfs

[Christopher Larson]

On Mon, Jan 11, 2016 at 5:57 AM Ahsan, Noor <Noor_Ahsan at mentor.com> wrote:

> 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
>
> Recommends: libc6-dev, libgcc-s-dev, ncurses-libtinfo-dev, ncurses-dev
>
> 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
>
> Depends: libtinfo5, ncurses (= 5.9-r15.1.6), libpanelw5, libform5,
> libtic5, libmenuw5, libformw5, libpanel5, libmenu5, libticw5
>
> So ncurses main package is installed indirectly if we install readline-dev.
>
> I thought that we should discuss this in community so that we can comeup
> with common decision.
>

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.

>From the bug (forgive the wall of text, I'm including it here for ease of
replying).:

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.

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.

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.

1. Enhance the rdep handling to map back to recipes
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 :)

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.

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.

Further commented:

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

Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20160316/3fda0330/attachment-0002.html>