On 8/4/12 3:59 AM, Laurentiu Palcu wrote:
On 08/04/2012 10:46 AM, Laurentiu Palcu wrote:
On 08/03/2012 11:25 PM, Mark Hatle wrote:
On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
Some postinst scriptlets test for the existence of certain files but
have the paths hardcoded to the target's rootfs. This patch will allow
us to run postinst scriptlets at do_rootfs time by calling native
binaries.
Signed-off-by: Laurentiu Palcu <laurentiu.pa...@intel.com>
---
meta/classes/package_rpm.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 50e9b31..113b19c 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -443,6 +443,7 @@ export D="${target_rootfs}"
export OFFLINE_ROOT="\$D"
export IPKG_OFFLINE_ROOT="\$D"
export OPKG_OFFLINE_ROOT="\$D"
+export NATIVE_DIR="${STAGING_DIR_NATIVE}"
Why is this needed? Normally the host items run from the path (and should know
how to access any related files they need), and ${D} points to the target rootfs
directory for things needing full paths.
Hmm, I think you're perfectly right... I needed it because the
gdk-pixbuf postinst scriplet tested the existence of
gtk-update-icon-cache binary but, now that you mentioned it, I realized
it might work without it. Test the existence of the binary on target
rootfs but run the native one from PATH.
However, I just remembered that the rpm packages are not installed in
dependency order... So, there might be packages, that need
gtk-update-icon-cache, installed before libgtk+ is installed. In this
case, the postinst scriptlets that test the existence of the binary on
the target rootfs will fail at do_roofts time... Unless a solution is
found to install the rpm packages in dependency order. BTW, is this
planned to be fixed?
Install order vs scriptlet order are different. The package dependencies
indicate when the transaction is complete all dependent packages will be
installed. The scriptlets can be delayed or run during the install process.
I'm not sure what controls when they run, but that is a separate action from the
actual install process itself.
I have not has the time to investigate the control of the scriptlets, but it's
on my list.
Back to the issue at hand though. Two solutions, the first is simply run the
program and if it fails, ignore the failure or "stage" it for later (or fail),
whichever is appropriate. The only thing that checking for the binary
accomplishes is knowing if it might fail or not, it's likely just as easy to
check for a failure trying to run the binary.
For the cross install case, you can check for the existence of the ${D}
variable. If it doesn't exist then you are on the target, and you can do
whatever checks are necessary -- but on the host side you will have to assume
the binary exists and is available [based on the recipe requirements.]
--Mark
Laurentiu
Thanks for the tip,
Laurentiu
--Mark
\$2 \$1/\$3 \$4
if [ \$? -ne 0 ]; then
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
