On Thu, 2017-01-19 at 18:17 -0200, Otavio Salvador wrote:

On Thu, Jan 19, 2017 at 5:47 PM, Patrick Ohly <patrick.ohly@...> wrote:

On Wed, 2017-01-18 at 21:26 +0000, Richard Purdie wrote:

On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:

Does that make it clearer why we need this?

I certainly understand it more.. I'm just struggling with how to
explain when
someone would need this or not, to someone who hasn't hit one of the
extraction
problems. I think that is by far my biggest remaining concern, how
to make
sure people can understand they need to do this and when...

The rules in some ways are simple, it comes down to:

"""
If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.
"""

Looking at this description, it is not at all clear to me why the
variable is named PACKAGE_WRITE_DEPENDS. From the description, the
things listed in it are dependencies of do_rootfs, not of
do_package_write_*, even if it happens to be implemented that way.

I like PS_NATIVE_DEPENDS better. Just my 2 cents.

PACKAGE_SCRIPTS_DEPENDS maps better to what they are intended to be
used for, I think.

Agreed, that's even better.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

On Thu, Jan 19, 2017 at 5:47 PM, Patrick Ohly <patrick.ohly@...> wrote:

On Wed, 2017-01-18 at 21:26 +0000, Richard Purdie wrote:

On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:

Does that make it clearer why we need this?

I certainly understand it more.. I'm just struggling with how to
explain when
someone would need this or not, to someone who hasn't hit one of the
extraction
problems. I think that is by far my biggest remaining concern, how
to make
sure people can understand they need to do this and when...

The rules in some ways are simple, it comes down to:

"""
If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.
"""

Looking at this description, it is not at all clear to me why the
variable is named PACKAGE_WRITE_DEPENDS. From the description, the
things listed in it are dependencies of do_rootfs, not of
do_package_write_*, even if it happens to be implemented that way.

I like PS_NATIVE_DEPENDS better. Just my 2 cents.

PACKAGE_SCRIPTS_DEPENDS maps better to what they are intended to be
used for, I think.


--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

On Wed, 2017-01-18 at 21:26 +0000, Richard Purdie wrote:

On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:

Does that make it clearer why we need this?

I certainly understand it more.. I'm just struggling with how to
explain when
someone would need this or not, to someone who hasn't hit one of the
extraction
problems. I think that is by far my biggest remaining concern, how
to make
sure people can understand they need to do this and when...

The rules in some ways are simple, it comes down to:

"""
If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.
"""

Looking at this description, it is not at all clear to me why the
variable is named PACKAGE_WRITE_DEPENDS. From the description, the
things listed in it are dependencies of do_rootfs, not of
do_package_write_*, even if it happens to be implemented that way.

I like PS_NATIVE_DEPENDS better. Just my 2 cents.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

On Thu, 2017-01-19 at 12:51 -0500, Randy MacLeod wrote:

Is there any chance that we could make 'do_populate_sysroot'
be the default task (with the possibility to over-ride)
so we'd have:

    PS_DEPENDS += "foo-native bar-native"

and since we've come this far... only -native dependencies are
sensible since this is running on the builder, so we could just have:

    PS_DEPENDS += "foo bar"

or if you want to spell it out:

    PS_NATIVE_DEPENDS += "foo bar"

I agree with stripping out the task piece, I was planning to work
something out with that. We could do with this cleanup in other places
too.

Not all have the form -native (we have some -cross) and I think that
removing that would be a step too far and make it much less clear what
these things were doing. 

Cheers,

Richard

On 2017-01-19 12:14 PM, Otavio Salvador wrote:

On Thu, Jan 19, 2017 at 2:56 PM, Jussi Kukkonen
<jussi.kukkonen@...> wrote:

Regarding the naming discussion: It would be great if it was somehow made
obvious to a recipe writer who adds a postinstall script that they may need
to add PACKAGE_WRITE_DEPS as well... but I don't really have practical
suggestions here.

What about DEPENDS_PKG_SCRIPTS ?

or PS_DEPENDS with the manual defining PS
and users thinking that it means any of:
Package Script / Populate Sysroot / Post Script

Also, all of Jussi's package changes are of the form:

PS_DEPENDS += "foo-native:do_populate_sysroot \
bar-native:do_populate_sysroot"

Is there any chance that we could make 'do_populate_sysroot'
be the default task (with the possibility to over-ride)
so we'd have:

PS_DEPENDS += "foo-native bar-native"

and since we've come this far... only -native dependencies are
sensible since this is running on the builder, so we could just have:

PS_DEPENDS += "foo bar"

or if you want to spell it out:

PS_NATIVE_DEPENDS += "foo bar"


--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5


















(where NATIVE is pronounced circus ... inside joke )

On Thu, Jan 19, 2017 at 2:56 PM, Jussi Kukkonen
<jussi.kukkonen@...> wrote:

Regarding the naming discussion: It would be great if it was somehow made
obvious to a recipe writer who adds a postinstall script that they may need
to add PACKAGE_WRITE_DEPS as well... but I don't really have practical
suggestions here.

What about DEPENDS_PKG_SCRIPTS ?

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

On Wed 2017-01-18 @ 09:26:53 PM, Richard Purdie wrote:

On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:
do_configure is special, we call its dependencies DEPENDS. 

There are special dependency requirements for do_package,
do_packagedata and RDEPENDS are actually only really mapped to
do_package_write_*.

...

The rules in some ways are simple, it comes down to:

"""
If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.
"""

Is there not already a mechanism for generically saying "I need <this> task of
<that> recipe to be completed before my <such-and-such> task can run" of which
DEPENDS and RDEPENDS are simply short-hand notations?

If "yes" (and I understand the discussion correctly) couldn't that be employed
here?

If "no" (and I understand the discussion correctly) wouldn't adding such a
mechanism be a possible solution. The use of which, hopefully, would make it
easier for a user to understand what's going on (without requiring ad-hoc
knowledge of the system)?

On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:

On 1/18/17 11:01 AM, Richard Purdie wrote:
The one thing I keep coming back to on DEPENDS (vs a more specific
DEPENDS).  In the general case, when I've built recipes I have say 'I
depend on XYZ', thinking then that anything XYZ depends on will be
available for me to build.

That would include the native items.  Now, that of course does NOT
mean they are required to unpack/'install into the sysroot' those
items, just that the dependencies exist for my current build.

The sysroot requirements are actually quite varied. It really helps to
think about this from a task perspective which is how bitbake really
works.

In order to run do_fetch, there could be tools like git-native or
subversion-native needed. In order to run do_patch, we need quilt-
native. 

do_configure is special, we call its dependencies DEPENDS. 

There are special dependency requirements for do_package,
do_packagedata and RDEPENDS are actually only really mapped to
do_package_write_*.

So bitbake handles dependencies on a per task basis and our task
dependencies are very convoluted and complex.

We then added sstate into the mix. For any given task, we need to know
which set of dependencies are really needed.

A-native can link against B-native so we must install B-native if we
install A-native.

If we install target package C, which native dependencies might we
need?

The problem is we have to give the system some kind of hint as it
really can't figure it out today and we've only ever hacked it to work.

What I'm trying to wrap my head around are the cases where you don't
depend on something for build time (or don't want a dependency to be
inherited) that won't cause more confusion over time.

An easy example, if I run "bitbake core-image-sato -c rootfs", would
you expect it to extract from sstate gcc-cross, binutils-cross and so
on? They're large and I suspect you'd agree they're not needed to build
a rootfs from sstate. The system doesn't pull them in today, nor should
it. cmake-native? bison-native? gettext-native? They do mount up
significantly.

I can certainly see the optimization cases where I know I only need
XYZ for the install, but the rest of the DEPENDS (and their DEPENDS)
are not needed.

So if I'm understanding this right.

If we did all DEPENDS inherited from our DEPENDS, then this would be
working properly.  But that means then all dependencies would need to
be installed each time, causing a huge performance impact --
especially on native dependencies which are often assumed or so?

Yes, particularly as we don't know how to draw the line at things like
the complete cross toolchain if we follow DEPENDS.

By default all DEPENDS (not native) will still be loaded and
inherited, and we're really only concerned with adding missing
'native' things that a specific install script may need?

I'm going to say yes for the purposes of this discussion. Its way more
complicated but not relevant.

So for performance reasons, we want to not automatically install all
of the dependent referred native packages -- and specify them as
needed -- only where needed..  helping performance by further being
able to delay the extract installation to as late as possible (the
package write function -- or equivalent sstate-cache install
functions [pre/post/etc]).

We won't delay extraction but we would remove the need to fetch and
extract these things and we're talking hundreds of MB which is
significant, particularly if you only want to rebuild a rootfs (e.g. in
the eSDK).

I think where I'm getting confused by the name is, that
PACKAGE_WRITE_DEPS
(equivalent of do_package_write*) sounds to me like something
required in order
to write the package to the disk.  So rpm, deb, opkg that kind of
thing would go there.

Unfortunately that is one of its uses too. I can't find any less
confusing way to handle it though which doesn't have its own added and
worse complexities.

It's not clear that the package's install script would be affected by
this in any way (nor the sstate-cache versions.)

(I'm struggling to come up with any name better then
PACKAGE_WRITE_DEPENDS myself...)

Right, I'm open to ideas but trying to explain how we end up here...

Does that make it clearer why we need this?

I certainly understand it more.. I'm just struggling with how to
explain when
someone would need this or not, to someone who hasn't hit one of the
extraction
problems.   I think that is by far my biggest remaining concern, how
to make
sure people can understand they need to do this and when...

The rules in some ways are simple, it comes down to:

"""
If your postinstall can execute at rootfs creation time rather than on
target but depends on a native tool in order to execute, you need to
list that tool in PACKAGE_WRITE_DEPENDS.
"""

Cheers,

Richard

On 1/18/17 11:01 AM, Richard Purdie wrote:

On Wed, 2017-01-18 at 09:24 -0600, Mark Hatle wrote:

I have seen other systems declare these in different ways. Things
like:

RPROVIDES_pn += "user(name)"

RREQUIRES_pn += "user(name)"

Automation can declare provides and dependencies users that are
need. But of course there will always be manual users/groups that
are needed as well.

You're thinking too specifically about my example. What about ca-
certificates which needs ca-certificates-native to run its postinstall
at do_rootfs time?

Keep in mind a -native dependency doesn't really make sense in a R*
namespace. This isn't really a package manager level problem but a
build system one. How do we know which -native dependencies a
postinstall needs?

yes, I was missing the native piece in my thinking.... I see why this is
potentially a big problem for the sstate-cache.

Theoretically we should already be doing some of this via
dependencies today -- but it can be a complex problem.

We have some gross hacks in the system today but nothing really marks
up which postinsts need which native dependencies.

Of course this doesn't handle other things postinsts may be needed
for...

Users are really just one very special case and the problem is much
wider.

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'm a little worried this is making things more complicated then they
may need to be.

What is the downside of simply specifying those items in the existing
DEPENDS as we have it today? (Performance, they have to be installed
before the package can begin to build?)

DEPENDS means "this recipe needs dependencies X at build time in order
to build so they must be available by do_configure".

We could insist all DEPENDS for all recipes are installed before we run
do_rootfs but that is a significant performance issue and a large set.

The one thing I keep coming back to on DEPENDS (vs a more specific DEPENDS). In
the general case, when I've built recipes I have say 'I depend on XYZ', thinking
then that anything XYZ depends on will be available for me to build.

That would include the native items. Now, that of course does NOT mean they are
required to unpack/'install into the sysroot' those items, just that the
dependencies exist for my current build.

With recipe specific sysroots, we've reached a point where we really do
need to know which dependencies postinstalls have IMO.

What I'm trying to wrap my head around are the cases where you don't depend on
something for build time (or don't want a dependency to be inherited) that won't
cause more confusion over time.

I can certainly see the optimization cases where I know I only need XYZ for the
install, but the rest of the DEPENDS (and their DEPENDS) are not needed.

So if I'm understanding this right.

If we did all DEPENDS inherited from our DEPENDS, then this would be working
properly. But that means then all dependencies would need to be installed each
time, causing a huge performance impact -- especially on native dependencies
which are often assumed or so?

By default all DEPENDS (not native) will still be loaded and inherited, and
we're really only concerned with adding missing 'native' things that a specific
install script may need?

So for performance reasons, we want to not automatically install all of the
dependent referred native packages -- and specify them as needed -- only where
needed.. helping performance by further being able to delay the extract
installation to as late as possible (the package write function -- or equivalent
sstate-cache install functions [pre/post/etc]).

The name itself doesn't make me understand (without reading your
explanation) why it's required. That also makes me suspect it might
be difficult (over time) to explain to people when they need this
behavior and why.

We could call it PACKAGE_POSTINST_DEPS. The issues here are that it
applies to PREINST too and that it really should list native deps, not
packaging deps. PACKAGE_WRITE_DEPS does accurately reflect where the
dependency goes and there are likely uses for this outside of
postinstalls as there are other places which have to spell out "add dep
X for deb, for ipk, for rpm).

I think where I'm getting confused by the name is, that PACKAGE_WRITE_DEPS
(equivalent of do_package_write*) sounds to me like something required in order
to write the package to the disk. So rpm, deb, opkg that kind of thing would go
there.

It's not clear that the package's install script would be affected by this in
any way (nor the sstate-cache versions.)

(I'm struggling to come up with any name better then PACKAGE_WRITE_DEPENDS
myself...)

I am hopeful that the number of places that need to reference this is
actually quite small and mostly in the core classes (like useradd,
systemd and so on). It really is a piece of core infrastructure rather
than something most developers would run into, and if they do need it,
the explains should make it clear how to use it. Code wise, the
additions are alongside the postinst pieces they apply to in the most
part.

Does that make it clearer why we need this?

I certainly understand it more.. I'm just struggling with how to explain when
someone would need this or not, to someone who hasn't hit one of the extraction
problems. I think that is by far my biggest remaining concern, how to make
sure people can understand they need to do this and when...

--Mark

Cheers,

Richard

On Wed, 2017-01-18 at 09:17 -0600, Sean Hudson wrote:

The suggested approach of adding a specific dependency for these
situations makes sense to me.  I am confused by the name
though.  What
do folks think about using 'POST_INST_DEPS' instead of
'PACKAGE_WRITE_DEPS'?

I keep going around in circles on this. The naming would then match one
use of it rather than where the dependency is added. It makes less
sense when you think this could apply to preinsts and its *not* about
target requirements, only native ones.

Cheers,

Richard

On Wed, 2017-01-18 at 09:24 -0600, Mark Hatle wrote:

I have seen other systems declare these in different ways.  Things
like:

RPROVIDES_pn += "user(name)"

RREQUIRES_pn += "user(name)"

Automation can declare provides and dependencies users that are
need.  But of course there will always be manual users/groups that
are needed as well.

You're thinking too specifically about my example. What about ca-
certificates which needs ca-certificates-native to run its postinstall
at do_rootfs time?

Keep in mind a -native dependency doesn't really make sense in a R*
namespace. This isn't really a package manager level problem but a
build system one. How do we know which -native dependencies a
postinstall needs?

Theoretically we should already be doing some of this via
dependencies today -- but it can be a complex problem.

We have some gross hacks in the system today but nothing really marks
up which postinsts need which native dependencies.

Of course this doesn't handle other things postinsts may be needed
for...

Users are really just one very special case and the problem is much
wider.

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'm a little worried this is making things more complicated then they
may need to be.

What is the downside of simply specifying those items in the existing
DEPENDS as we have it today?  (Performance, they have to be installed
before the package can begin to build?)

DEPENDS means "this recipe needs dependencies X at build time in order
to build so they must be available by do_configure".

We could insist all DEPENDS for all recipes are installed before we run
do_rootfs but that is a significant performance issue and a large set.

With recipe specific sysroots, we've reached a point where we really do
need to know which dependencies postinstalls have IMO.

The name itself doesn't make me understand (without reading your
explanation) why it's required.  That also makes me suspect it might
be difficult (over time) to explain to people when they need this
behavior and why.

We could call it PACKAGE_POSTINST_DEPS. The issues here are that it
applies to PREINST too and that it really should list native deps, not
packaging deps. PACKAGE_WRITE_DEPS does accurately reflect where the
dependency goes and there are likely uses for this outside of
postinstalls as there are other places which have to spell out "add dep
X for deb, for ipk, for rpm).

I am hopeful that the number of places that need to reference this is
actually quite small and mostly in the core classes (like useradd,
systemd and so on). It really is a piece of core infrastructure rather
than something most developers would run into, and if they do need it,
the explains should make it clear how to use it. Code wise, the
additions are alongside the postinst pieces they apply to in the most
part.

Does that make it clearer why we need this?

Cheers,

Richard

On 1/18/17 8:23 AM, Richard Purdie wrote:

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?

I have seen other systems declare these in different ways. Things like:

RPROVIDES_pn += "user(name)"

RREQUIRES_pn += "user(name)"

Automation can declare provides and dependencies users that are need. But of
course there will always be manual users/groups that are needed as well.

Theoretically we should already be doing some of this via dependencies today --
but it can be a complex problem.

Of course this doesn't handle other things postinsts may be needed for...

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'm a little worried this is making things more complicated then they may need
to be.

What is the downside of simply specifying those items in the existing DEPENDS as
we have it today? (Performance, they have to be installed before the package
can begin to build?)

The name itself doesn't make me understand (without reading your explanation)
why it's required. That also makes me suspect it might be difficult (over time)
to explain to people when they need this behavior and why.

--Mark

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.

Cheers,

Richard


From c8c37b97427e37852f2a6efc14b5337422489116 Mon Sep 17 00:00:00 2001
From: Richard Purdie <richard.purdie@...>
Date: Wed, 18 Jan 2017 12:33:16 +0000
Subject: PACKAGE_WRITE_DEPS first pass

Signed-off-by: Richard Purdie <richard.purdie@...>

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index c5d8d7c..1e75bde 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -2,6 +2,8 @@ FILES_${PN} += "${datadir}/icons/hicolor"

DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk-icon-utils-native"

+PACKAGE_WRITE_DEPS += "gtk-icon-utils-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"
+
gtk_icon_cache_postinst() {
if [ "x$D" != "x" ]; then
$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} \
diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index efe1b42..c7f4880 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -22,6 +22,8 @@ if [ x"$D" = "x" ]; then
fi
}

+PACKAGE_WRITE_DEPS += "kmod-native:do_populate_sysroot depmodwrapper-cross:do_populate_sysroot"
+
do_install_append() {
install -d ${D}${sysconfdir}/modules-load.d/ ${D}${sysconfdir}/modprobe.d/
}
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 568b85c..0a56d1c 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -54,6 +54,8 @@ ALL_MULTILIB_PACKAGE_ARCHS = "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"
# rpm is used for the per-file dependency identification
PACKAGE_DEPENDS += "rpm-native"

+PACKAGE_WRITE_DEPS ??= ""
+
def legitimize_package_name(s):
"""
Make sure package names are legitimate strings
diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 68eca61..d4f9262 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -351,6 +351,7 @@ python do_package_write_deb () {
do_package_write_deb[dirs] = "${PKGWRITEDIRDEB}"
do_package_write_deb[cleandirs] = "${PKGWRITEDIRDEB}"
do_package_write_deb[umask] = "022"
+do_package_write_deb[depends] += "${PACKAGE_WRITE_DEPS}"
addtask package_write_deb after do_packagedata do_package


diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index 7018a60..9def81b 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -291,6 +291,7 @@ python do_package_write_ipk () {
do_package_write_ipk[dirs] = "${PKGWRITEDIRIPK}"
do_package_write_ipk[cleandirs] = "${PKGWRITEDIRIPK}"
do_package_write_ipk[umask] = "022"
+do_package_write_ipk[depends] += "${PACKAGE_WRITE_DEPS}"
addtask package_write_ipk after do_packagedata do_package

PACKAGEINDEXDEPS += "opkg-utils-native:do_populate_sysroot"
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index b9f049e..d07ac51 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -772,6 +772,7 @@ python do_package_write_rpm () {
do_package_write_rpm[dirs] = "${PKGWRITEDIRRPM}"
do_package_write_rpm[cleandirs] = "${PKGWRITEDIRRPM}"
do_package_write_rpm[umask] = "022"
+do_package_write_rpm[depends] += "${PACKAGE_WRITE_DEPS}"
addtask package_write_rpm after do_packagedata do_package

PACKAGEINDEXDEPS += "rpm-native:do_populate_sysroot"
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index 0295a66..3f5b6ef 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -8,7 +8,7 @@ inherit qemu

PIXBUF_PACKAGES ??= "${PN}"

-do_package_write_rpm[depends] += "qemu-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"
+PACKAGE_WRITE_DEPS += "qemu-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"

pixbufcache_common() {
if [ "x$D" != "x" ]; then
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index e84e2d9..9500303 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -938,17 +938,14 @@ BB_SETSCENE_DEPVALID = "setscene_depvalid"
def setscene_depvalid(task, taskdependees, notneeded, d):
# taskdependees is a dict of tasks which depend on task, each being a 3 item list of [PN, TASKNAME, FILENAME]
# task is included in taskdependees too
+ # Return - False - We need this dependency
+ # - True - We can skip this dependency

bb.debug(2, "Considering setscene task: %s" % (str(taskdependees[task])))

def isNativeCross(x):
return x.endswith("-native") or "-cross-" in x or "-crosssdk" in x or x.endswith("-cross")

- def isPostInstDep(x):
- if x in ["qemu-native", "gdk-pixbuf-native", "qemuwrapper-cross", "depmodwrapper-cross", "systemd-systemctl-native", "gtk-icon-utils-native", "ca-certificates-native"]:
- return True
- return False
-
# We only need to trigger populate_lic through direct dependencies
if taskdependees[task][1] == "do_populate_lic":
return True
@@ -970,10 +967,11 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
# do_package_write_* and do_package doesn't need do_package
if taskdependees[task][1] == "do_package" and taskdependees[dep][1] in ['do_package', 'do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package_qa']:
continue
- # do_package_write_* and do_package doesn't need do_populate_sysroot, unless is a postinstall dependency
- if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package', 'do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package_qa']:
- if isPostInstDep(taskdependees[task][0]) and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm']:
- return False
+ # do_package_write_* need do_populate_sysroot as they're mainly postinstall dependencies
+ if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm']:
+ return False
+ # do_package/packagedata/package_qa don't need do_populate_sysroot
+ if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package', 'do_packagedata', 'do_package_qa']:
continue
# Native/Cross packages don't exist and are noexec anyway
if isNativeCross(taskdependees[dep][0]) and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package', 'do_package_qa']:
diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 0b1c228..3e33456 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -17,6 +17,7 @@ python __anonymous() {
# files.
if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
d.appendVar("DEPENDS", " systemd-systemctl-native")
+ d.appendVar("PACKAGE_WRITE_DEPS", " systemd-systemctl-native:do_populate_sysroot")
if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
}
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 5bf81c4..7fdfca5 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -4,6 +4,7 @@ inherit useradd_base
# target sysroot, and shadow -native and -sysroot provide the utilities
# and support files needed to add and modify user and group accounts
DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot shadow base-passwd"
+PACKAGE_WRITE_DEPS += "shadow-native:do_populate_sysroot"

# This preinstall function can be run in four different contexts:
#
diff --git a/meta/recipes-bsp/keymaps/keymaps_1.0.bb b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
index 5793a76..adea233 100644
--- a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
+++ b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
@@ -37,7 +37,7 @@ do_install () {
fi
}

-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
pkg_postinst_${PN} () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd sysvinit','true','false',d)}; then
if [ -n "$D" ]; then
diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
index 1046d63..8bd3700 100644
--- a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
+++ b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
@@ -60,7 +60,7 @@ python __anonymous() {

inherit update-rc.d

-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
pkg_postinst_${PN} () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd sysvinit','true','false',d)}; then
if [ -n "$D" ]; then
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 8f110b0..836e9eb 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -44,7 +44,7 @@ KERNEL_VERSION = ""

inherit update-alternatives
DEPENDS_append = " update-rc.d-native"
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"

PACKAGES =+ "${PN}-functions"
RDEPENDS_${PN} = "${PN}-functions \
diff --git a/meta/recipes-core/psplash/psplash_git.bb b/meta/recipes-core/psplash/psplash_git.bb
index b0d6bb4..335593d 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -110,7 +110,7 @@ FILES_${PN} += "/mnt/.psplash"
INITSCRIPT_NAME = "psplash.sh"
INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."

-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
pkg_postinst_${PN} () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
if [ -n "$D" ]; then
diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb b/meta/recipes-core/systemd/systemd-compat-units.bb
index 0f0876b..7655246 100644
--- a/meta/recipes-core/systemd/systemd-compat-units.bb
+++ b/meta/recipes-core/systemd/systemd-compat-units.bb
@@ -4,7 +4,7 @@ LICENSE = "MIT"

PR = "r29"

-DEPENDS = "systemd-systemctl-native"
+PACKAGE_WRITE_DEPS += "systemd-systemctl-native:do_populate_sysroot"

S = "${WORKDIR}"

diff --git a/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb b/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
index db670cf..9b602a5 100644
--- a/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
+++ b/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
@@ -22,7 +22,7 @@ do_install () {
install -m 0755 ${WORKDIR}/modutils.sh ${D}${sysconfdir}/init.d/
}

-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
pkg_postinst_${PN} () {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
if [ -n "$D" ]; then
diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
index 42c742f..bf0de36 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
@@ -6,7 +6,6 @@ LICENSE = "GPLv2.0+"
LIC_FILES_CHKSUM = "file://session;endline=3;md5=f8a5c5b9c279e52dc094d10e11c2be63"

SECTION = "x11"
-DEPENDS = "gconf-native"
RDEPENDS_${PN} = "formfactor matchbox-theme-sato matchbox-panel-2 matchbox-desktop matchbox-session gconf"
PR = "r30"

@@ -43,6 +42,7 @@ do_install() {
chmod +x ${D}/${sysconfdir}/matchbox/session
}

+PACKAGE_WRITE_DEPS += "gconf-native:do_populate_sysroot"
pkg_postinst_${PN} () {
set_value() {
#type, name, value
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
index e0b2e41..1c70408 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = "file://debian/copyright;md5=e7358b9541ccf3029e9705ed8de57968
DEPENDS = "ca-certificates-native"
DEPENDS_class-native = "openssl-native"
DEPENDS_class-nativesdk = "ca-certificates-native openssl-native"
+PACKAGE_WRITE_DEPS += "ca-certificates-native:do_populate_sysroot"

SRCREV = "61b70a1007dc269d56881a0d480fc841daacc77c"



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

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.

Cheers,

Richard


From c8c37b97427e37852f2a6efc14b5337422489116 Mon Sep 17 00:00:00 2001
From: Richard Purdie <richard.purdie@...>
Date: Wed, 18 Jan 2017 12:33:16 +0000
Subject: PACKAGE_WRITE_DEPS first pass

Signed-off-by: Richard Purdie <richard.purdie@...>

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index c5d8d7c..1e75bde 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -2,6 +2,8 @@ FILES_${PN} += "${datadir}/icons/hicolor"
 
 DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk-icon-utils-native"
 
+PACKAGE_WRITE_DEPS += "gtk-icon-utils-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"
+
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
  $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} \
diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index efe1b42..c7f4880 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -22,6 +22,8 @@ if [ x"$D" = "x" ]; then
 fi
 }
 
+PACKAGE_WRITE_DEPS += "kmod-native:do_populate_sysroot depmodwrapper-cross:do_populate_sysroot"
+
 do_install_append() {
  install -d ${D}${sysconfdir}/modules-load.d/ ${D}${sysconfdir}/modprobe.d/
 }
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 568b85c..0a56d1c 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -54,6 +54,8 @@ ALL_MULTILIB_PACKAGE_ARCHS = "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"
 # rpm is used for the per-file dependency identification
 PACKAGE_DEPENDS += "rpm-native"
 
+PACKAGE_WRITE_DEPS ??= ""
+
 def legitimize_package_name(s):
     """
     Make sure package names are legitimate strings
diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 68eca61..d4f9262 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -351,6 +351,7 @@ python do_package_write_deb () {
 do_package_write_deb[dirs] = "${PKGWRITEDIRDEB}"
 do_package_write_deb[cleandirs] = "${PKGWRITEDIRDEB}"
 do_package_write_deb[umask] = "022"
+do_package_write_deb[depends] += "${PACKAGE_WRITE_DEPS}"
 addtask package_write_deb after do_packagedata do_package
 
 
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index 7018a60..9def81b 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -291,6 +291,7 @@ python do_package_write_ipk () {
 do_package_write_ipk[dirs] = "${PKGWRITEDIRIPK}"
 do_package_write_ipk[cleandirs] = "${PKGWRITEDIRIPK}"
 do_package_write_ipk[umask] = "022"
+do_package_write_ipk[depends] += "${PACKAGE_WRITE_DEPS}"
 addtask package_write_ipk after do_packagedata do_package
 
 PACKAGEINDEXDEPS += "opkg-utils-native:do_populate_sysroot"
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index b9f049e..d07ac51 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -772,6 +772,7 @@ python do_package_write_rpm () {
 do_package_write_rpm[dirs] = "${PKGWRITEDIRRPM}"
 do_package_write_rpm[cleandirs] = "${PKGWRITEDIRRPM}"
 do_package_write_rpm[umask] = "022"
+do_package_write_rpm[depends] += "${PACKAGE_WRITE_DEPS}"
 addtask package_write_rpm after do_packagedata do_package
 
 PACKAGEINDEXDEPS += "rpm-native:do_populate_sysroot"
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index 0295a66..3f5b6ef 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -8,7 +8,7 @@ inherit qemu
 
 PIXBUF_PACKAGES ??= "${PN}"
 
-do_package_write_rpm[depends] += "qemu-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"
+PACKAGE_WRITE_DEPS += "qemu-native:do_populate_sysroot gdk-pixbuf-native:do_populate_sysroot"
 
 pixbufcache_common() {
 if [ "x$D" != "x" ]; then
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index e84e2d9..9500303 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -938,17 +938,14 @@ BB_SETSCENE_DEPVALID = "setscene_depvalid"
 def setscene_depvalid(task, taskdependees, notneeded, d):
     # taskdependees is a dict of tasks which depend on task, each being a 3 item list of [PN, TASKNAME, FILENAME]
     # task is included in taskdependees too
+    # Return - False - We need this dependency
+    #        - True - We can skip this dependency
 
     bb.debug(2, "Considering setscene task: %s" % (str(taskdependees[task])))
 
     def isNativeCross(x):
         return x.endswith("-native") or "-cross-" in x or "-crosssdk" in x or x.endswith("-cross")
 
-    def isPostInstDep(x):
-        if x in ["qemu-native", "gdk-pixbuf-native", "qemuwrapper-cross", "depmodwrapper-cross", "systemd-systemctl-native", "gtk-icon-utils-native", "ca-certificates-native"]:
-            return True
-        return False
-
     # We only need to trigger populate_lic through direct dependencies
     if taskdependees[task][1] == "do_populate_lic":
         return True
@@ -970,10 +967,11 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
         # do_package_write_* and do_package doesn't need do_package
         if taskdependees[task][1] == "do_package" and taskdependees[dep][1] in ['do_package', 'do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package_qa']:
             continue
-        # do_package_write_* and do_package doesn't need do_populate_sysroot, unless is a postinstall dependency
-        if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package', 'do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package_qa']:
-            if isPostInstDep(taskdependees[task][0]) and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm']:
-                return False
+        # do_package_write_* need do_populate_sysroot as they're mainly postinstall dependencies
+        if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm']:
+            return False
+        # do_package/packagedata/package_qa don't need do_populate_sysroot
+        if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package', 'do_packagedata', 'do_package_qa']:
             continue
         # Native/Cross packages don't exist and are noexec anyway
         if isNativeCross(taskdependees[dep][0]) and taskdependees[dep][1] in ['do_package_write_deb', 'do_package_write_ipk', 'do_package_write_rpm', 'do_packagedata', 'do_package', 'do_package_qa']:
diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 0b1c228..3e33456 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -17,6 +17,7 @@ python __anonymous() {
     # files.
     if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
         d.appendVar("DEPENDS", " systemd-systemctl-native")
+        d.appendVar("PACKAGE_WRITE_DEPS", " systemd-systemctl-native:do_populate_sysroot")
         if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
             d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
 }
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 5bf81c4..7fdfca5 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -4,6 +4,7 @@ inherit useradd_base
 # target sysroot, and shadow -native and -sysroot provide the utilities
 # and support files needed to add and modify user and group accounts
 DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot shadow base-passwd"
+PACKAGE_WRITE_DEPS += "shadow-native:do_populate_sysroot"
 
 # This preinstall function can be run in four different contexts:
 #
diff --git a/meta/recipes-bsp/keymaps/keymaps_1.0.bb b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
index 5793a76..adea233 100644
--- a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
+++ b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
@@ -37,7 +37,7 @@ do_install () {
     fi
 }
 
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
 pkg_postinst_${PN} () {
  if ${@bb.utils.contains('DISTRO_FEATURES','systemd sysvinit','true','false',d)}; then
  if [ -n "$D" ]; then
diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
index 1046d63..8bd3700 100644
--- a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
+++ b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
@@ -60,7 +60,7 @@ python __anonymous() {
 
 inherit update-rc.d
 
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
 pkg_postinst_${PN} () {
  if ${@bb.utils.contains('DISTRO_FEATURES','systemd sysvinit','true','false',d)}; then
  if [ -n "$D" ]; then
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 8f110b0..836e9eb 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -44,7 +44,7 @@ KERNEL_VERSION = ""
 
 inherit update-alternatives
 DEPENDS_append = " update-rc.d-native"
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
 
 PACKAGES =+ "${PN}-functions"
 RDEPENDS_${PN} = "${PN}-functions \
diff --git a/meta/recipes-core/psplash/psplash_git.bb b/meta/recipes-core/psplash/psplash_git.bb
index b0d6bb4..335593d 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -110,7 +110,7 @@ FILES_${PN} += "/mnt/.psplash"
 INITSCRIPT_NAME = "psplash.sh"
 INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."
 
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
 pkg_postinst_${PN} () {
  if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
  if [ -n "$D" ]; then
diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb b/meta/recipes-core/systemd/systemd-compat-units.bb
index 0f0876b..7655246 100644
--- a/meta/recipes-core/systemd/systemd-compat-units.bb
+++ b/meta/recipes-core/systemd/systemd-compat-units.bb
@@ -4,7 +4,7 @@ LICENSE = "MIT"
 
 PR = "r29"
 
-DEPENDS = "systemd-systemctl-native"
+PACKAGE_WRITE_DEPS += "systemd-systemctl-native:do_populate_sysroot"
 
 S = "${WORKDIR}"
 
diff --git a/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb b/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
index db670cf..9b602a5 100644
--- a/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
+++ b/meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb
@@ -22,7 +22,7 @@ do_install () {
  install -m 0755 ${WORKDIR}/modutils.sh ${D}${sysconfdir}/init.d/
 }
 
-DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
+PACKAGE_WRITE_DEPS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native:do_populate_sysroot','',d)}"
 pkg_postinst_${PN} () {
  if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
  if [ -n "$D" ]; then
diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
index 42c742f..bf0de36 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
@@ -6,7 +6,6 @@ LICENSE = "GPLv2.0+"
 LIC_FILES_CHKSUM = "file://session;endline=3;md5=f8a5c5b9c279e52dc094d10e11c2be63"
 
 SECTION = "x11"
-DEPENDS = "gconf-native"
 RDEPENDS_${PN} = "formfactor matchbox-theme-sato matchbox-panel-2 matchbox-desktop matchbox-session gconf"
 PR = "r30"
 
@@ -43,6 +42,7 @@ do_install() {
         chmod +x ${D}/${sysconfdir}/matchbox/session
 }
 
+PACKAGE_WRITE_DEPS += "gconf-native:do_populate_sysroot"
 pkg_postinst_${PN} () {
  set_value() {
  #type, name, value
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
index e0b2e41..1c70408 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20161130.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = "file://debian/copyright;md5=e7358b9541ccf3029e9705ed8de57968
 DEPENDS = "ca-certificates-native"
 DEPENDS_class-native = "openssl-native"
 DEPENDS_class-nativesdk = "ca-certificates-native openssl-native"
+PACKAGE_WRITE_DEPS += "ca-certificates-native:do_populate_sysroot"
 
 SRCREV = "61b70a1007dc269d56881a0d480fc841daacc77c"