Packaged staging and what it gives

Many people do not realize that Poky (and OpenEmbedded .dev) have so called “packaged staging” support.

What it is?

Let me try to describe it a bit. During normal builds “tmp/staging” directory is populated during do_stage tasks and there is no way to remove staged files in other way then by hand. With “packaged staging” this area is under package management — each built recipe has those files packaged along with resulting packages, stamps and cross tools.

OK, but what it gives? Why to bother with this at all?

Those are good questions… With fast machines (like my Core2Quad for example) build of “poky-image-sato” can be done in less then 2 hours so it looks like there is no need for any speedups… But not every one has such beasts. With packaged staging developer is able to do repeatable builds in nearly no time (compared to first build) as most of recipes are not built but unpacked from previous builds.

How to use it

To make use of packaged staging “conf/local.conf” needs some editing. Basically one line (inheriting packaged staging class) is important:

INHERIT += "packaged-staging"

To be able to make builds from scratch one more change (moving directory with staging packages outside of “tmp”) is needed:

DEPLOY_DIR_PSTAGE = "${OEROOT}/build/pstage/"

After those edits we need to make first build. I suggest “poky-image-sato” target as this will give all important libraries built and packaged. Everything behave like in normal build — software is built, staged, packaged and final image is created. Bonus is in “${OEROOT}/build/pstage/” subdirectories — extra packages which will be used in any of next builds.

Lets test it

Now when we have first built done (which took few hours) we can test how much will “packaged staging” improve our build time (I assume that both edits listed above were done).

So now comes interesting part — we will remove “tmp” directory and do build from scratch. Please notice what happens — nearly nothing is built (except “stagemanager-native” which handle “packaged staging” functionality) because everything is unpacked from packages done on previous build. If any recipe got updated since last time it will be built and packaged.

End notes

As you see packaged staging can be really useful for making builds — less time is needed, results of following builds are same. And in the end developer has more time for developing :)

5 thoughts on “Packaged staging and what it gives

  1. koen

    Angstrom has enabled packaged-staging by default for some months now. It is a real timesaver when trying to track down dependency problems.

  2. yans

    How about package modifications ? Let’s say I modified a “pname” recipe that has already been built. Is it going to be rebuild when I ask for it (bitbake -f -c clear pname; bitbake pname ) or regenerated from pstage with no modifications ?

  3. yans

    How about package modifications ? Let’s say I modified a “pname” recipe that has already been built. Is it going to be rebuild when I ask for it (bitbake -f -c clear pname; bitbake pname ) or regenerated from pstage with no modifications ?

    PS. Why does posing comments involve ssl ? A bonus for ssl at your site is a firefox error “ssl_error_bad_cert_domain” – cert was generated for *.kei.pl and not for .biz … Or I am wrong – and some one is really sniffing my posts :P

Comments are closed.

No Trackbacks.