One problem we're seeing with recipe specific sysroots (rss) is that
the dependencies package postinstalls have is badly represented.

For example, dbus adds a user and this needs tools from shadow-native.

If you run a do_rootfs build from an empty TMPDIR and have a populated
sstate cache, how does the system know it needs to install shadow-
native from sstate so that dbus' postinsts aren't deferred to on
target?

Currently its a bit of mess/hack. There is a list of hardcoded special
cases in sstate.bbclass but its incomplete. There are also lists of
special dependencies in the image.bbclass rootfs code to pull in things
like depmodwrapper-cross and ldconfig.

Some things are detected at build time like ldconfig dependencies so
there isn't much that can be done for them but most dependencies like
depmod, useradd, gtk-icon-cache, gdk-pixbuf, systemd and so on are
known in advance.

With rss, the problem gets more complicated since not only do we need
to ensure the tools get extracted from sstate but that they must get
into the image recipe's own native sysroot.

I've spent quite some time pondering how to do this. A normal DEPENDS
means something quite different so we need some kind of new markup.
Adding new kinds of dependencies to bitbake doesn't seem attractive
though.

I'm going to propose a new PACKAGE_WRITE_DEPS variable which gets added
to the [depends] flag of the do_package_write_XXX tasks.

What this means is that the dependency is indicated in the task graph
and its done in a generic way which the code can identify and act upon.
These tasks don't currently have much in the way of dependencies other
than tools to actually build packages.

The PACKAGE_WRITE_DEPS can either be in addition to DEPENDS if the
recipe needs these tools at build time, or if its only needed for the
postinst, PACKAGE_WRITE_DEPS can be sufficient and the DEPENDS can be
removed.

I've had a go at a quick proof of concept patch below. This includes
removing the hardcoded pieces from sstate.bbclass but I'm still in the
process of testing this.

Right now, I wanted to put this proposal out there and see if people
were ok with the general idea. There are perhaps some tweaks that could
be made to the final implementation. I am conscious the M2 deadline is
looming and if we want rss in this release, we need to be thinking
about merging code soon though.