[RFC] Disable packaged-staging for perl-native

[RFC] Disable packaged-staging for perl-native

[Tom Rini]

I'd like to disable packaged-staging for perl-native.  The problem here 
comes from a number of things that happen.  Some of these can only 
happen in combination with packaged-staging but others I believe could 
happen today.  The problem itself is that if we have perl-native 
available from packaged-staging it can suddenly exist very early.  What 
this means in practical terms is that now we're trying to generate say 
pod2man.pl from pod2man.pl.in and @perl@ is expanded to something beyond 
the "#!" mechanic length limit and recipes start failing to build 
(fixable by changing pod2man.pl.in to use /usr/bin/env perl (and if it 
had a -w changing to Use warnings: or whatever the perl is)).

There may have been other rats nests I ran into but can't fully confirm 
weren't due to other crazy rats nests I made.  But we hit the above many 
times.

perl-native: Disable packaged-staging

Having perl-native come from packaged-staging can expose other issues.
Disable so we get the normal (potential) behavior here.

Signed-off-by: Tom Rini <tom_rini@mentor.com>

diff --git a/recipes/perl/perl-native_5.10.1.bb 
b/recipes/perl/perl-native_5.10.1.bb
index 0e0854b..98c2c3c 100644
--- a/recipes/perl/perl-native_5.10.1.bb
+++ b/recipes/perl/perl-native_5.10.1.bb
@@ -9,6 +9,9 @@ NATIVE_INSTALL_WORKS = "1"
  # Not tested enough
  DEFAULT_PREFERENCE = "-1"

+# Introduces issues when re-used too early.
+PSTAGING_DISABLED = "1"
+
  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/perl-${PV}"

  SRC_URI = 
"http://ftp.funet.fi/pub/CPAN/src/perl-${PV}.tar.gz;name=perl-${PV} \
diff --git a/recipes/perl/perl-native_5.8.8.bb 
b/recipes/perl/perl-native_5.8.8.bb
index fe1bc84..b966eeb 100644
--- a/recipes/perl/perl-native_5.8.8.bb
+++ b/recipes/perl/perl-native_5.8.8.bb
@@ -6,6 +6,9 @@ DEPENDS = "virtual/db-native gdbm-native"
  PR = "r20"
  NATIVE_INSTALL_WORKS = "1"

+# Introduces issues when re-used too early.
+PSTAGING_DISABLED = "1"
+
  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/perl-${PV}"

  SRC_URI = "http://ftp.funet.fi/pub/CPAN/src/5.0/perl-${PV}.tar.gz \

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC] Disable packaged-staging for perl-native

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28-07-10 01:45, Tom Rini wrote:
> I'd like to disable packaged-staging for perl-native.  The problem here
> comes from a number of things that happen.  Some of these can only
> happen in combination with packaged-staging but others I believe could
> happen today.  The problem itself is that if we have perl-native
> available from packaged-staging it can suddenly exist very early.  What
> this means in practical terms is that now we're trying to generate say
> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something beyond
> the "#!" mechanic length limit and recipes start failing to build
> (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and if it
> had a -w changing to Use warnings: or whatever the perl is)).
> 
> There may have been other rats nests I ran into but can't fully confirm
> weren't due to other crazy rats nests I made.  But we hit the above many
> times.
> 
> perl-native: Disable packaged-staging
> 
> Having perl-native come from packaged-staging can expose other issues.
> Disable so we get the normal (potential) behavior here.

In the past 'perl-native' was actually 'perl-cross', you needed to
rebuild it when changing archs. Dunno if that still is the case.

regards,

Koen

> 
> Signed-off-by: Tom Rini <tom_rini@mentor.com>
> 
> diff --git a/recipes/perl/perl-native_5.10.1.bb
> b/recipes/perl/perl-native_5.10.1.bb
> index 0e0854b..98c2c3c 100644
> --- a/recipes/perl/perl-native_5.10.1.bb
> +++ b/recipes/perl/perl-native_5.10.1.bb
> @@ -9,6 +9,9 @@ NATIVE_INSTALL_WORKS = "1"
>  # Not tested enough
>  DEFAULT_PREFERENCE = "-1"
> 
> +# Introduces issues when re-used too early.
> +PSTAGING_DISABLED = "1"
> +
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/perl-${PV}"
> 
>  SRC_URI =
> "http://ftp.funet.fi/pub/CPAN/src/perl-${PV}.tar.gz;name=perl-${PV} \
> diff --git a/recipes/perl/perl-native_5.8.8.bb
> b/recipes/perl/perl-native_5.8.8.bb
> index fe1bc84..b966eeb 100644
> --- a/recipes/perl/perl-native_5.8.8.bb
> +++ b/recipes/perl/perl-native_5.8.8.bb
> @@ -6,6 +6,9 @@ DEPENDS = "virtual/db-native gdbm-native"
>  PR = "r20"
>  NATIVE_INSTALL_WORKS = "1"
> 
> +# Introduces issues when re-used too early.
> +PSTAGING_DISABLED = "1"
> +
>  FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/perl-${PV}"
> 
>  SRC_URI = "http://ftp.funet.fi/pub/CPAN/src/5.0/perl-${PV}.tar.gz \
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMT9eTMkyGM64RGpERAuaEAJ9kzPdQLHDcX/GfqTNWFTzMngqzuwCgr3nc
eHEzHXwGeLNBlf6PKpfvRcE=
=roO2
-----END PGP SIGNATURE-----

Re: [RFC] Disable packaged-staging for perl-native

[Roman I Khimov]

В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:
> I'd like to disable packaged-staging for perl-native.  The problem here
> comes from a number of things that happen.  Some of these can only
> happen in combination with packaged-staging but others I believe could
> happen today.  The problem itself is that if we have perl-native
> available from packaged-staging it can suddenly exist very early.  What
> this means in practical terms is that now we're trying to generate say
> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something beyond
> the "#!" mechanic length limit and recipes start failing to build
> (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and if it
> had a -w changing to Use warnings: or whatever the perl is)).

So the problem really is that we have perl in /very-very-long-path/perl? IMO 
/usr/bin/env change would be better in that case. 

Re: [RFC] Disable packaged-staging for perl-native

[Tom Rini]

Roman I Khimov wrote:
> В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:
>> I'd like to disable packaged-staging for perl-native.  The problem here
>> comes from a number of things that happen.  Some of these can only
>> happen in combination with packaged-staging but others I believe could
>> happen today.  The problem itself is that if we have perl-native
>> available from packaged-staging it can suddenly exist very early.  What
>> this means in practical terms is that now we're trying to generate say
>> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something beyond
>> the "#!" mechanic length limit and recipes start failing to build
>> (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and if it
>> had a -w changing to Use warnings: or whatever the perl is)).
> 
> So the problem really is that we have perl in /very-very-long-path/perl? IMO 
> /usr/bin/env change would be better in that case. 

The most common case is that one, yes.  I'm open to suggestions on 
catching and fixing these problems ahead of time but the issue is we're 
talking about for example wget which has no dependency on perl-native.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC] Disable packaged-staging for perl-native

[Tom Rini]

Tom Rini wrote:
> Roman I Khimov wrote:
>> В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:
>>> I'd like to disable packaged-staging for perl-native.  The problem here
>>> comes from a number of things that happen.  Some of these can only
>>> happen in combination with packaged-staging but others I believe could
>>> happen today.  The problem itself is that if we have perl-native
>>> available from packaged-staging it can suddenly exist very early.  What
>>> this means in practical terms is that now we're trying to generate say
>>> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something beyond
>>> the "#!" mechanic length limit and recipes start failing to build
>>> (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and if it
>>> had a -w changing to Use warnings: or whatever the perl is)).
>>
>> So the problem really is that we have perl in 
>> /very-very-long-path/perl? IMO /usr/bin/env change would be better in 
>> that case. 
> 
> The most common case is that one, yes.  I'm open to suggestions on 
> catching and fixing these problems ahead of time but the issue is we're 
> talking about for example wget which has no dependency on perl-native.

As I go over the list of stuff to get a "1.0" of relocatable packaged 
staging done, ping?  Blacklist perl-native for now or someone suggest 
how to catch and fixup all the cases to be /usr/bin/env perl ?  iirc 
just setting ac_cv...="/usr/bin/env perl" won't do it since we end up 
trying to invoke /usr/bin/env perl -w sometimes and that's an error.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC] Disable packaged-staging for perl-native

[Roman I Khimov]

[-- Attachment #1: Type: Text/Plain, Size: 2317 bytes --]

В сообщении от Четверг 12 августа 2010 21:12:22 автор Tom Rini написал:
> Tom Rini wrote:
> > Roman I Khimov wrote:
> >> В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:
> >>> I'd like to disable packaged-staging for perl-native.  The problem here
> >>> comes from a number of things that happen.  Some of these can only
> >>> happen in combination with packaged-staging but others I believe could
> >>> happen today.  The problem itself is that if we have perl-native
> >>> available from packaged-staging it can suddenly exist very early.  What
> >>> this means in practical terms is that now we're trying to generate say
> >>> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something
> >>> beyond the "#!" mechanic length limit and recipes start failing to
> >>> build (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and
> >>> if it had a -w changing to Use warnings: or whatever the perl is)).
> >>
> >> So the problem really is that we have perl in
> >> /very-very-long-path/perl? IMO /usr/bin/env change would be better in
> >> that case.
> >
> > The most common case is that one, yes.  I'm open to suggestions on
> > catching and fixing these problems ahead of time but the issue is we're
> > talking about for example wget which has no dependency on perl-native.
> 
> As I go over the list of stuff to get a "1.0" of relocatable packaged
> staging done, ping?  Blacklist perl-native for now or someone suggest
> how to catch and fixup all the cases to be /usr/bin/env perl ?  iirc
> just setting ac_cv...="/usr/bin/env perl" won't do it since we end up
> trying to invoke /usr/bin/env perl -w sometimes and that's an error.

Well, IMO, blacklisting just doesn't fix the problem here if the problem is 
/long/long/long/path/to/perl. Because whether from packaged staging or from 
really built perl-native the perl will be there anyway and so is the chance of 
breakage.

Maybe some automatic

$ sed -ri "s,#!.\s*${STAGING_NATIVE_BINDIR}/perl,#!/usr/bin/env perl,"

somewhere (and probably something more hacky to only catch the first line)?

-- 
 http://roman.khimov.ru
mailto: roman@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC] Disable packaged-staging for perl-native

[Tom Rini]

Roman I Khimov wrote:
> В сообщении от Четверг 12 августа 2010 21:12:22 автор Tom Rini написал:
>> Tom Rini wrote:
>>> Roman I Khimov wrote:
>>>> В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:
>>>>> I'd like to disable packaged-staging for perl-native.  The problem here
>>>>> comes from a number of things that happen.  Some of these can only
>>>>> happen in combination with packaged-staging but others I believe could
>>>>> happen today.  The problem itself is that if we have perl-native
>>>>> available from packaged-staging it can suddenly exist very early.  What
>>>>> this means in practical terms is that now we're trying to generate say
>>>>> pod2man.pl from pod2man.pl.in and @perl@ is expanded to something
>>>>> beyond the "#!" mechanic length limit and recipes start failing to
>>>>> build (fixable by changing pod2man.pl.in to use /usr/bin/env perl (and
>>>>> if it had a -w changing to Use warnings: or whatever the perl is)).
>>>> So the problem really is that we have perl in
>>>> /very-very-long-path/perl? IMO /usr/bin/env change would be better in
>>>> that case.
>>> The most common case is that one, yes.  I'm open to suggestions on
>>> catching and fixing these problems ahead of time but the issue is we're
>>> talking about for example wget which has no dependency on perl-native.
>> As I go over the list of stuff to get a "1.0" of relocatable packaged
>> staging done, ping?  Blacklist perl-native for now or someone suggest
>> how to catch and fixup all the cases to be /usr/bin/env perl ?  iirc
>> just setting ac_cv...="/usr/bin/env perl" won't do it since we end up
>> trying to invoke /usr/bin/env perl -w sometimes and that's an error.
> 
> Well, IMO, blacklisting just doesn't fix the problem here if the problem is 
> /long/long/long/path/to/perl. Because whether from packaged staging or from 
> really built perl-native the perl will be there anyway and so is the chance of 
> breakage.

Yes, it's a very broken thing Today.  It's just rarely if ever hit 
today.  But with packaged staging it happens a lot, especially when you 
have a lot of threads.

> Maybe some automatic
> 
> $ sed -ri "s,#!.\s*${STAGING_NATIVE_BINDIR}/perl,#!/usr/bin/env perl,"
> 
> somewhere (and probably something more hacky to only catch the first line)?

And it also needs to either change perl -w to Use::Warnings or so, or 
just drop that out.  And hope that everything that might use it is a 
foo.pl.in.  If it is, we could add a mangle_perl hook before 
do_configure after do_patch, inside of autotools.bbclass (or just make 
it happen in there?).

-- 
Tom Rini
Mentor Graphics Corporation