<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 January 2017 at 16:23, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">One problem we're seeing with recipe specific sysroots (rss) is that<br>
the dependencies package postinstalls have is badly represented.<br>
<br>
For example, dbus adds a user and this needs tools from shadow-native.<br>
<br>
If you run a do_rootfs build from an empty TMPDIR and have a populated<br>
sstate cache, how does the system know it needs to install shadow-<br>
native from sstate so that dbus' postinsts aren't deferred to on<br>
target?<br>
<br>
Currently its a bit of mess/hack. There is a list of hardcoded special<br>
cases in sstate.bbclass but its incomplete. There are also lists of<br>
special dependencies in the image.bbclass rootfs code to pull in things<br>
like depmodwrapper-cross and ldconfig.<br>
<br>
Some things are detected at build time like ldconfig dependencies so<br>
there isn't much that can be done for them but most dependencies like<br>
depmod, useradd, gtk-icon-cache, gdk-pixbuf, systemd and so on are<br>
known in advance.<br>
<br>
With rss, the problem gets more complicated since not only do we need<br>
to ensure the tools get extracted from sstate but that they must get<br>
into the image recipe's own native sysroot.<br>
<br>
I've spent quite some time pondering how to do this. A normal DEPENDS<br>
means something quite different so we need some kind of new markup.<br>
Adding new kinds of dependencies to bitbake doesn't seem attractive<br>
though.<br>
<br>
I'm going to propose a new PACKAGE_WRITE_DEPS variable which gets added<br>
to the [depends] flag of the do_package_write_XXX tasks.<br>
<br>
What this means is that the dependency is indicated in the task graph<br>
and its done in a generic way which the code can identify and act upon.<br>
These tasks don't currently have much in the way of dependencies other<br>
than tools to actually build packages.<br>
<br>
The PACKAGE_WRITE_DEPS can either be in addition to DEPENDS if the<br>
recipe needs these tools at build time, or if its only needed for the<br>
postinst, PACKAGE_WRITE_DEPS can be sufficient and the DEPENDS can be<br>
removed.<br>
<br>
</div></div>I've had a go at a quick proof of concept patch below. This includes<br>
removing the hardcoded pieces from sstate.bbclass but I'm still in the<br>
process of testing this.<br>
<span class="gmail-"><br>
Right now, I wanted to put this proposal out there and see if people<br>
</span>were ok with the general idea. There are perhaps some tweaks that could<br>
be made to the final implementation. I am conscious the M2 deadline is<br>
looming and if we want rss in this release, we need to be thinking<br>
about merging code soon though.<br></blockquote><div><br></div><div>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 <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/wip-rss">http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/wip-rss</a>. The branch is based on Richards rpurdie/wip-rss -- but I did test this (Richards) patch and mine on top of master first.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Jussi<br></div><div><br></div><div><br></div></div></div></div>