On Sat, 2011-05-07 at 18:02 +0000, Robin H. Johnson wrote:
> On Fri, May 06, 2011 at 09:05:08AM -0700, Junio C Hamano wrote:
> > The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
> > should expects the path to the program.
> >
> > Our testsuite also rely on it being the path to the program by enclosing
> > the reference to it inside double quotes, to make sure that PERL_PATH set
> > to "/Program Files/Perl/perl.exe" works. Didn't Gentoo folks see any test
> > breakage before shipping the ebuild procedure?
> The entire test suite completes fine with our
> PERL_PATH="${EPREFIX}/usr/bin/env perl" setting.
>
> This was originally put into place because of our bug #326625 [1].
> >From that bug:
> ====
> Git does not compile if local::lib installed in user's home directory if
> 'sudo' is used to raise privileges. Local::lib exports environment
> variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.
> Variable PREFIX is set in package's Makefile.pl. Package will not
> compile if both of these variables are set.
> ====
> (Full logs attached in the bug).
>
> If you can suggest a better way to fix the user's bug, I'll revert the
> PERL_PATH change.
>
> 1. https://bugs.gentoo.org/show_bug.cgi?id=326625
Robin,
What user are you running the ebuild as? All setting PERL_PATH this way
does is set Perl up to run with a modified environment (quite likely
completely trashing it in this case) which would explain why the ebuild
completes.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html