Disable packaged-staging for perl-native

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 <[email protected]>

recipes/perl/perl-native_5.10.1.bb +3 -0

index 0e0854b..98c2c3c 100644
@@ -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} \

recipes/perl/perl-native_5.8.8.bb +0 -0

index fe1bc84..b966eeb 100644

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)).

В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:

Quoted 10 lines

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.

Quoted 12 lines · Roman I Khimov

В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:

Quoted 10 lines

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)).

Quoted 1 line

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.

Quoted 13 lines · Tom Rini

Quoted 12 lines · Roman I Khimov

В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:

Quoted 10 lines

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)).

Quoted 7 lines

Quoted 3 lines

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.

В сообщении от Четверг 12 августа 2010 21:12:22 автор Tom Rini написал:

Quoted 19 lines

Quoted 18 lines · Tom Rini

Quoted 11 lines · Roman I Khimov

В сообщении от Среда 28 июля 2010 03:45:21 автор Tom Rini написал:

Quoted 10 lines

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)).

Quoted 3 lines

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.

Quoted 5 lines

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)?