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

[Richard Purdie]

On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> On 06/02/2011 07:37 AM, Phil Blundell wrote:
> > On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
> >> But help2man is just the easy/common case.  Heck, it _may_ blow up even
> >> with the host help2man instead of help2man-native, if a recipe uses
> >> system-wide help2man and perlnative.bbclass.  The root problem (again,
> >> from memory) is that since we modify PERL5LIB and so on, when we do
> >> that, we've opened ourselves up for system-wide perl trying to use
> >> perl-native's stuff.
> > 
> > Ah right, I think I see what you're getting at now.
> > 
> > If we've got a clean separation between perl-native and host perl,
> > though, can't we now just eliminate all of that futzing with PERL5LIB in
> > cpan.bbclass and such like places?  perl-native already knows how to
> > look in the right places within the sysroot for its modules so there
> > should be no need for anything else to be overriding it.
> 
> Well, my question is, does it, really?

If it doesn't it really does need to get fixed. I've not seen any
evidence this has been the problem but it still could be.

>   Even if we're using the sstate
> cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
> is rm -rf'd) ?  Since we've got a create_wrapper around perl and
> perl${PV} it should be I suppose (or is easily added there), but I'd
> feel a lot better with some testing of the above case (and the updates
> to cpan*bbclass).

I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...

Cheers,

Richard