[oe] Packaged Staging, nearly a reality!
Richard Purdie
rpurdie at rpsys.net
Sat Dec 1 23:47:39 UTC 2007
As anyone watching the commits will notice, OE just gained the next
generation of packaged staging support! :)
To use simply INHERIT = "packaged-staging2". Staging packages end up in
tmp/deploy/pstage. To accelerate your next build, copy them into the
tmp/deploy/pstage directory in that build and it will take advantage of
them.
As with rm_work, there is the problem of the work directory being
missing if you try and then subsequently run tasks like configure or
compile. To avoid the staged version and trigger a manual build run
'bitbake xyz -c fetch -f'.
There are some problems:
* A handful of packages are missing from deploy/ipk and deploy/deb,
specifically those from gcc-cross (libgcc* and libstdc++*).
Ultimately, I think we'll need to change gcc's packaging as this
experiment has highlighted some fundamental problems with it (and see
the comment I added to meta-toolchain.bb with a similar problem).
* Builds can crash out when building an image when trying to create
the installkit because zImage-foobar.bin is missing. This is due to
deploy/images not being part of the staging tarballs.
* Its using ipkg. It made Marcin/me finally track down the stupid
"can't create /usr/lib/ipkg" bug. ipkg has no locking so when
multiple threads install to staging at the same time things went
horribly wrong and the status file was corrupted. It was quite
amusing to watch but I've added locking in the tasks now.
* Due to locking, only one populate_staging can run at once (other may
look like they are but they'll be blocking on a lock). Bitbake really
needs to become aware of lock contention but I'll settle for working
safely atm. I have plans to change the way staging works to address
this and get some speed back, removing the need for stage-manager in
the process.
* The .la files will be corrupt when installed into a new build. Some
sed magic is needed.
* -native packages aren't covered since these are compiled with build
specific paths. -native packages aren't skipped even if the build
doesn't need them directly, sadly :(. Extremely painful to fix (I'm
not even sure how) but can be hacked around, see below.
* -cross packages aren't covered but they don't need to be, we can use
meta-toolchain to handle these.
* The -native and -cross packages in staging are not under packaging
control at present.
* We create too many stamps when accelerating.
Looks like a long list but nothing fundamental IMO! :)
To give an idea of the speedup this brings, I managed a build of a GUI
image in 6 minutes 14 seconds which included recompiling a package that
had changed and all the -native packages. I used the ASSUME_PROVIDED at
the end of the mail to skip some -native packages I didn't need in this
case.
Neat features:
* If the PR of any package has changed it will rebuild just those
changed packages since it realises the staging packages aren't current
enough.
* When you clean a package, the staged files are uninstalled from
staging.
* Any package can be rebuilt, altered etc. nearly the same as a normal
poky build bearing in mind the need for "-c fetch -f".
* -cross packages are covered by using meta-toolchain.
I've not yet tried installing just the depends of a given recipe but
this should be possible and will introduce a neat way of testing recipe
DEPENDS :).
Anyone feeling brave can try this, just keep in mind it is highly
experimental. There are bugs and work remains although hopefully others
can help from here. It has a lot of potential and I suspect its a
glimpse into the future :).
Cheers,
Richard
ASSUME_PROVIDED += "\
openssl-native \
git-native \
qemu-native \
libtool-native \
gettext-native \
automake-native \
perl-native \
libxml-parser-perl-native \
dbus-native \
libxml2-native \
db-native \
pkgconfig-native \
gtk-doc-native \
tzcode-native \
xorg-headers-native \
glib-2.0-native \
dbus-glib-native \
intltool-native \
desktop-file-utils-native \
pax-util-native \
freetype-native \
fontconfig-native \
unzip-native \
util-macros-native \
flex-native \
curl-native \
zlib-native \
file-native \
bison-native \
ncurses-native"
More information about the Openembedded-devel
mailing list