[Openembedded-architecture] Package postinstall dependencies - Introduction of PACKAGE_WRITE_DEPS

[Jussi Kukkonen]

On 18 January 2017 at 16:23, Richard Purdie <
richard.purdie at linuxfoundation.org> 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?
>
> 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.
>

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
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/wip-rss.
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.

Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20170119/25830f7a/attachment-0002.html>