Re: Package postinstall dependencies - Introduction of PACKAGE_WRITE_DEPS
On Wed, 2017-01-18 at 11:57 -0600, Mark Hatle wrote:
On 1/18/17 11:01 AM, Richard Purdie wrote:The sysroot requirements are actually quite varied. It really helps to
think about this from a task perspective which is how bitbake really
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-
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
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
If we install target package C, which native dependencies might we
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'tAn 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
I can certainly see the optimization cases where I know I only needYes, 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 andI'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 allWe 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
I think where I'm getting confused by the name is, thatUnfortunately 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
It's not clear that the package's install script would be affected byRight, I'm open to ideas but trying to explain how we end up here...
The rules in some ways are simple, it comes down to:Does that make it clearer why we need this?I certainly understand it more.. I'm just struggling with how 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.