Created attachment 669 [details]
Simplistic fix to handle alternate Perl handling

You can call 
  perl Makefile.PL PERL_BIN=/some/perl 
to override the perl you use. If you don't pass a PERL_BIN, the path from 
$Config{'perlpath'} is used. Here this works so far... 
 
What does 
  perl5.6.1 -e 'use Config; print $Config{'perlpath'};' 
give you? 

$ perl5.6.1 -e 'use Config; print $Config{'perlpath'};'
/usr/bin/perl

I didn't do anything special when I installed Perl (i.e. -Uinstallusrbinperl),
since I intended 5.6.1 to be the current version of Perl on this computer (til I
discovered exactly how stupid the Cobalt distro was designed).

In any case, if I had installed 5.8.0, then decided that I wanted to run
SpamAssassin using an already installed instance of 5.6.1 (say, because I was
running a UTF-8 distro ;~), each Perl installation would consider itself to be
/usr/bin/perl, even though the most recent would be the only one linked that way.

Hence, whatever version of Perl I use to call Makefile.PL must be the one that
is propagated to the scripts.

Hmmm... so you built your Perl to be installed in /usr/bin/perl but didn't put 
it there, right? So your Perl installation is broken ;-) Howevery, I think it 
should be ok to fall back to $self->{PERL} if $self->{PERL_BIN} is not set and 
thus overriding the find-perlbin-code in preprocessor. But I have to check if 
this is compatible with older (and newer) Perls first. 
 
But be warned (*drumbeat* ;-): The sharpbang replacement code is taken from 
ExtUtils::MakeMaker; it uses $Config{'perlpath'}, too. So it might happen that 
you encounter problems when you install other packages carrying perl scripts 
(eg. LWP). 

Fair enough, by some definition of 'broken' my Perl is broken, but my second
paragraph still stands.  All Perl's assume you are going to install them as
/usr/bin/perl unless you tell them otherwise.  Nonetheless, you are able to have
multiple Perl's installed and use whichever one you want by calling it with the
fully qualified executable name.

Would this be more acceptable?

  my $perl_bin     = $self->{PERL_BIN}     || $self->{PERL} || 'this';

Otherwise, a small doc patch to mention the currently undocumented:

  /some/perl Makefile.PL PERL_BIN=/some/perl 

would be appropriate.  Since there are ongoing UTF-8 issues with 5.8.0, I can
see people wanting to use 5.6.x instead and we should be very careful to not
only permit that but facilitate it.

That's the way I intend to do it. And you're right, we should really document 
the supported parameters to Makefile.PL in INSTALL. I'm gonna do it. 

we should use the "perl" referred to on the left-hand-side of the

  /some/perl5.n.n Makefile.PL

command, if we can -- is that {PERL}?  if so, I say go for that. it's
neater (and more DWIM) than a new config parameter on the command line...

There's now patch (attachment 1304 [details]) in bug 2388 against 2.60-RC3. It makes the 
determination a bit more sophisticated: 
* All the stuff can still be set via PERL_* 
* PERL_BIN will default to $(FULLPERL), normally the current interpreter 
* $(PERL_BIN) will be called and the version read from the output. If that 
can't be determined (ie. you build a package for a system which has Perl in 
/some/weird/location on another system), it defaults to the current 
interpreters version. 
 
That's all I can do.