Proc::FastSpawn test failure

[Darin McBride]

On Saturday November 23 2013 12:06:13 PM Marc Lehmann wrote:
> On Fri, Nov 22, 2013 at 11:58:48PM -0700, Darin McBride 
<darin.mcbride at shaw.ca> wrote:
> > > There's nothing relocatable about that - you simply break your perl
> > > installation that way.
> > 
> > Yes, that's relocatable.
> 
> Sorry, no, "relocatable" doesn't mean "break our perl".

Well, in general, people use $^X to compensate.  Have you tried using -
Duserelocatableinc?  

> > I use -Duserelocatableinc on the Configure command line as well.
> 
> Which doesn't relocate your perl, nor make your perl relocatable. It can
> help with the process, but as the name implies, doesn't do the whole job
> obviously.

The instructions do indicate that this is all that is required.  From 
perl589delta:

   Relocatable installations
       There is now Configure support for creating a relocatable perl tree. If
       you Configure with "-Duserelocatableinc", then the paths in @INC (and
       everything else in %Config) can be optionally located via the path of
       the perl executable.

       At start time, if any paths in @INC or "Config" that Configure marked
       as relocatable (by starting them with ".../"), then they are prefixed
       the directory of $^X. This allows the relocation can be configured on a
       per-directory basis, although the default with "-Duserelocatableinc" is
       that everything is relocated. The initial install is done to the
       original configured prefix.

So long as you move the entire tree as a unit, which is all I've done (I just 
didn't install it to the original location first), it's supposed to be fine.

> > While I didn't make it explicit earlier, in my original note I
> > did say "relocatable perl" which I thought implied this flag.
> 
> I am not sure what role the flag plays in this - the flag doesn't
> cause any issues, does it?

It allows the perl tree to be relocated.  So I relocated it.  And now 
Proc::FastSpawn has a failure because it's relying on a non-relocated config 
var.  Arguably, this is a bug in perl itself (see 
https://rt.perl.org/Ticket/Display.html?id=112448 ).  But this is where we're 
at at the moment.

> > > That's because you haven't relocated your perl, you just moved it
> > > away. That jsut destroys your install, it doesn't relocate it.
> > 
> > I haven't _re_-located it, no.  But it's relocatable, as per the normal
> > method for relocating on Unix.
> 
> Can you refer me to any official specification for this "normal method
> for relocating on unix"? Because there is no normal way for relocating
> on unix, and if there were, it would NOT include "break your perl
> installation".

It's mostly in perl589delta, perl51000delta, with some in INSTALL and mentions 
in perl5143delta and perl5144delta.  It probably needs more dedicated 
documentation.

> What you did is simply move your perl without relocating it. That breaks
> things. If you want to relocate your perl, you need to do it properly,
> according to the documented way of doing things.

Which is, roughly, paraphrasing, "mv srcdir dstdir".  Just move the entire 
tree.

> > That's fine, but I highly disagree that this is a broken install.
> 
> You don't have to agree at all - it's up to you if you want to be
> unreasonable.

That's an interesting perspective.

> Your perl has a broken Config. It's broken because it gives the wrong
> values for docmented configuration directives. That makes it broken
> whether you agree to it or not.

I'm following the documentation.  Whether perl's relocatableness is broken or 
not is another story, but, at the moment, perlpath does not indicate where 
perl is currently installed to ($^X is the most reliable method of determining 
that) but only where it was initially told it would go, with no guarantees it 
would still be there.

> The relocatable issue is a red herring. Being relocatable or relocating
> your perl does not cause the problem. Breaking your perl config by giving
> bogus values to modules is the problem.

I didn't do any of that, please don't unreasonably accuse.

> There is nothing else to say from my side - you can fix your perl, or you
> can leave it broken, but that is your personal issue.

Out of 168 CPAN distributions I'm using, this is the only outstanding failure 
due to being relocated.  Even AnyEvent::Fork and friends don't have any issue 
using $^X instead of $Config{perlpath}.  My original suggestion for this issue 
was really to do pretty much exactly what you are doing in AnyEvent::Fork: use 
$^X, but, if that doesn't work, fall back to checking $Config{perlpath}.  That 
was it.  That should work fine even with relocatable perl, when following the 
instructions to do so, as I have been doing.