[oe] [oe-commits] Carsten Haitzler (Rasterman : angstrom, exquisite, psplash, opkg, angsrtom-images, sysvinit: abstract splash

Graeme Gregory dp at xora.org.uk
Wed Apr 29 10:47:46 UTC 2009


GIT User account wrote:
> Module: openembedded.git
> Branch: org.openembedded.dev
> Commit: 212e36417ae27e1be11147168b6f5cdfd1c5eda9
> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=212e36417ae27e1be11147168b6f5cdfd1c5eda9
>
> Author: Carsten Haitzler (Rasterman <raster at rasterman.com>
> Date:   Fri Apr 17 15:44:58 2009 +1000
>
> angstrom, exquisite, psplash, opkg, angsrtom-images, sysvinit: abstract splash
>
> this abstracts psplash to be generic. now as long as something provides a
> splashfuncs file that sysvinit (and other scripts) can source, and all the
> approproate init hooks to start the splash etc. you can use psplash,
> exquisitie, usplash or anything that tickles your fancy. this moves splash
> toa ${SPLASH} variable to include in your image (or override). the default in
> angstrom is psplash - unless you override it. opkg also runs a configure
> script that cna take forever - and so this speically sends off some splash
> commands (if there) to let you know the systme is alive and working (but just
> busy).
>
> this is one commit as if this breaks things you either want to fix the minor
> break or totally revert the whole patch. i hope it didn't break anything.
>
>  recipes/opkg/files/configure                       |   18 ++++++++++++
>   
Taken me a while to notice, but the backgrounding of opkg configure in
this file totally breaks booting cleanly on first boot. It causes a race
condition on whether the necessary packages are configured before X
manages to launch. Is it really required that opkg be backgrounded at
this point?

Also Im not convinced about the deleting of S98configure, this breaks
the situation when a device dies during opkg configure (most commonly
when dbus shuts down which kills pretty much everything) as packages
dont get configured on next boot to finish the operation.

This is not worthy of a revert, just some more thought!

Graeme





More information about the Openembedded-devel mailing list