[3/5] dpkg: Fix usage of create_wrapper

Submitted by Saul Wold on June 10, 2013, 9:45 p.m.

Details

Message ID 1370900715-29294-4-git-send-email-sgw@linux.intel.com
State New
Headers show

Commit Message

Saul Wold June 10, 2013, 9:45 p.m.
create_wrapper changed recently and behaves differently now. It does
not directly exec the , but exports them, so the first parameter
needs to be an environemnt variable like a PATH, not a executable.

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/recipes-devtools/dpkg/dpkg.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc b/meta/recipes-devtools/dpkg/dpkg.inc
index 28c4f89..02383ed 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -56,7 +56,7 @@  do_install_append () {
 do_install_append_class-native () {
 	tmp=`find ${D}${bindir} -type f -exec grep -m 1 -l '#!/.*/perl-native/perl' {} \;`
 	for i in $tmp; do
-		create_wrapper $i ${STAGING_BINDIR_NATIVE}/perl-native/perl
+		create_wrapper $i PATH=${STAGING_BINDIR_NATIVE}/perl-native:\$PATH
 	done
 }
 

Comments

Ross Burton June 11, 2013, 1:57 p.m.
On 10 June 2013 22:45, Saul Wold <sgw@linux.intel.com> wrote:
> create_wrapper changed recently and behaves differently now. It does
> not directly exec the , but exports them, so the first parameter
> needs to be an environemnt variable like a PATH, not a executable.
>
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/recipes-devtools/dpkg/dpkg.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/dpkg/dpkg.inc b/meta/recipes-devtools/dpkg/dpkg.inc
> index 28c4f89..02383ed 100644
> --- a/meta/recipes-devtools/dpkg/dpkg.inc
> +++ b/meta/recipes-devtools/dpkg/dpkg.inc
> @@ -56,7 +56,7 @@ do_install_append () {
>  do_install_append_class-native () {
>         tmp=`find ${D}${bindir} -type f -exec grep -m 1 -l '#!/.*/perl-native/perl' {} \;`
>         for i in $tmp; do
> -               create_wrapper $i ${STAGING_BINDIR_NATIVE}/perl-native/perl
> +               create_wrapper $i PATH=${STAGING_BINDIR_NATIVE}/perl-native:\$PATH

NACK.

The message isn't entirely accurate - the changes to the wrapper
scripts were consistent with the documentation of the function which
clearly says the arguments are NAME=VALUE pairs, but recipes such as
this were using "insider" knowledge that the wrapper was implemented
with "env" to effectively inject perl-native so that is the binary
executed, not the real script itself.  This avoids the stupidly small
buffer in binfmt_script that parses the #! lines (128 bytes), which is
what the comment above this block refers to.

Setting the path won't perform this workaround, so this patch (and
similar) re-introduces the problem with deeply nested work
directories.

I guess the real question is why do we wrap scripts one by one instead
of doing some wrapping centrally when writing to the native sysroot
itself?  At the moment we're playing whack-a-mole where sufficient
scripts have been wrapped that a specific build appears to work.

Ross