Re: Package postinstall dependencies - Introduction of PACKAGE_WRITE_DEPS

Jussi Kukkonen <jussi.kukkonen@...>

On 18 January 2017 at 16:23, Richard Purdie <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

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

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

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.

Richard asked me to test this and look at the remaining unhandled postinstalls. I've now done that, patches for the missing PACKAGE_WRITE_DEPS are in the "jku/wip-rss" branch in poky-contrib The branch is based on Richards rpurdie/wip-rss -- but I did test this (Richards) patch  and mine on top of master first.

It all seems to work fine: I've not managed to break the dependency handling yet and things like running target tools via qemu in postinstall seem to do the right thing.  I'll continue testing though: especially with recipe-specific-sysroots there's quite a few new things to grasp so it's a little slower going than normal.

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.


Join { to automatically receive all group messages.