* rebuild recipes depending on vendor_perl.
* beware though, haikuporter might wrongly select both perl 5.18 and
perl 5.26 in the chroot to satisfy the dependencies.
Passing /bin/perl (instead of $portPackageLinksDir/cmd~perl/bin/perl)
as PERL_PATH to make in makeGit solves the issue about perl not being
found when "haikuporter --test git" is run. FWIW, that path is used
to set the PERL and FULLPERL variables in $sourceDir/perl/perl.mak.
TEST() does not work yet because of haikuports/haikuporter/issues/90
but adding BUILD_PACKAGE_ACTIVATION_PHASE=TEST and playing with the
time stamp of the recipe (once built) can help workaround this error:
Testing ...
SUBDIR perl
/bin/sh: /packages/git-2.9.0-1/cmd~perl/bin/perl: No such file or directory
Besides hopefully speeding up git when using large repositories such as
HaikuPorts and Haiku itself, this fixes an error thrown when doing anything
involving `git config --system`.
* Referring the current haiku version explicitly is not needed, since
the RequiresUpdater takes care of setting the version of Haiku used
for building a package.
* portVersionedName contains the secondary architecture,
so using it means secondary package builds fail.
example: $portVersionedName is libwow_x86-0.0.0 when
doing an x86 build on x86_gcc2
* Add new package git_remote_helpers, which provides a python module.
* Add requires for vendor_perl, as providing a vendor perl module
requires a specific perl version.
* Declare settings directory.
* perl -> cmd:perl, python -> cmd:python
* cmd:man, cmd:nano, cmd:perl, cmd:python are actually build requires in
this case, since the build system will look for them to decide on
features.
