[OE-core] [PATCH 3/5] dpkg: Fix usage of create_wrapper

[Burton, Ross]

On 10 June 2013 22:45, Saul Wold <sgw at 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 at 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