diff options
| author | Kevin Tian <kevin.tian@intel.com> | 2010-08-11 13:34:54 +0800 |
|---|---|---|
| committer | Richard Purdie <rpurdie@linux.intel.com> | 2010-08-12 15:39:24 +0100 |
| commit | e101642a61fc418273c1cd4d58a9564b4bdecc5c (patch) | |
| tree | 8890d90be0403bd1a9161f32ceb3d5cd1b7a27b5 /meta/packages/module-init-tools | |
| parent | cf1e754b3fee3c7ae907e7ae30233083d7892215 (diff) | |
| download | openembedded-core-e101642a61fc418273c1cd4d58a9564b4bdecc5c.tar.gz openembedded-core-e101642a61fc418273c1cd4d58a9564b4bdecc5c.tar.bz2 openembedded-core-e101642a61fc418273c1cd4d58a9564b4bdecc5c.tar.xz openembedded-core-e101642a61fc418273c1cd4d58a9564b4bdecc5c.zip | |
populate-volatile.sh: cleanup duplicated invocations and remove boot warning
For one, populate-volatile.sh is itself a rcS script which is invoked earlier
than package's own postinst method (last one in rcS). If package has already
installed their volatile files correctly, it doesn't make sense to update volatile
again in postinst since nothing is changed.
On the other hand, dbus/hal are special since their user/group are only created
in the target. If they pre-install volatiles like others, populate-volatile.sh
will report "undefined user" since at that time their user/group haven't been
created. The better way solving this is to generate their volatile in the fly
after user/group are created, and then update volatiles.
This fix [BUGID #121]
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Diffstat (limited to 'meta/packages/module-init-tools')
0 files changed, 0 insertions, 0 deletions