diff options
author | Mark Hatle <mark.hatle@windriver.com> | 2017-08-18 14:12:33 -0500 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2017-08-19 09:19:12 +0100 |
commit | e31c9d32072b9cf62c0e9e55b4d421849d3d489b (patch) | |
tree | 01ee0d0c8cbb703d589d78b4b717fe65f5ba350f /scripts/lib/devtool/search.py | |
parent | 2f1f3480d344f8521e01f456d2dcd6c4e989ec59 (diff) | |
download | openembedded-core-e31c9d32072b9cf62c0e9e55b4d421849d3d489b.tar.gz openembedded-core-e31c9d32072b9cf62c0e9e55b4d421849d3d489b.tar.bz2 openembedded-core-e31c9d32072b9cf62c0e9e55b4d421849d3d489b.zip |
prelink: Change the behavior to avoid checking USER_CLASSES
The behavior before this change was to check USER_CLASSES and adjust
the install script to return either exit 0 (don't do anything) or
exit 1 (run on first boot). This enabled a user to include the prelink
package without enablign the image-prelink bbclass and get a first boot
prelink.
Checking USER_CLASSES is not desired, as an image should be able to simply
inherit the image-prelink and get the same type of behavior. Modifying
the recipe based on the inclusion of a class is a bad idea as it makes
this style work more difficult. So we move to a more defined strategy
based on exist uses. (That we know of...)
If we ae doing a cross install, we want to avoid prelinking.
Prelinking during a cross install should be handled by the image-prelink
bbclass. If the user desires this to run on the target at first boot
they will need to create a custom boot script.
[YOCTO #11169]
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'scripts/lib/devtool/search.py')
0 files changed, 0 insertions, 0 deletions