[OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

[Cui, Dexuan]

Tom Rini wrote:
> On 06/01/2011 01:05 PM, Phil Blundell wrote:
>> On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote:
>>> Maybe race isn't quite the right word.  But recipe A depends on
>>> lib$something-perl-native, and brings in perl-native.  It also
>>> checks 
>>> for perl in its auto-foo and finds our perl.  It now also uses our
>>> perl when it wants a host perl and all of the potential bad things
>>> happen, yes? 
>> 
>> What are the circumstances in which it would want a host perl?  I
>> don't quite understand the issue here.  Surely anything that the
>> host perl can do, perl-native plus some combination of
>> libfoo-perl-native can also do, right?
> 
> So, here's the two things going on:
> - In some cases (libfoo-perl-native) we need to install various perl
> modules in order to build other target apps.  This is the cpan case,
> iirc.  We don't currently (and can't?) just play whatever games perl
> would like to do to use system-wide perl and a local to TMPDIR cpan
> directory.  We instead go down the path of having perl-native.
> - In order to build perl for the target we need to have the same perl
> version available for use.
> 
> What we do in oe-core (and oe.dev, historically) is provide
> perl-native 
> for both of these cases.  What falls down in this case is that  once
> perl-native is built (and in our PATH), if it's a different version
> than system-wide perl, stuff starts failing on version mis-match. 
> The patch series here fixes that by saying stuff must opt-in to
> having perl-native 
> be in PATH rather than just system-wide perl.  What I'm saying is that
> while in oe-core nothing falls down here (since nothing that gets
> perl-native also tries to just run 'perl') meta-oe is or will have
> failures. 
> 
> Unfortunately I don't have the test cases that drove me to make oe.dev
> like it is handy but I have a feeling that if we go down this path it
> won't be the last we see of the problem, but it might well pop up
> again. 
> 
> There is another option here, which is to make perl-native be
> perl-cross, live in its own special directory and figure out how to
> make 
> a TMPDIR-specific cpan repository available for use by system-wide
> perl. 

Hi Tom,
Thank you very much for the detailed explanation!
However I'm actually new to cpan and know few about the history of that in oe.dev, so I'm not sure I know enough about the background to make a proper decision now.
I suppose Richard would comment here. :-)

Thanks,
-- Dexuan