Junio C Hamano <gits...@pobox.com> writes:

> [query about NetBSD-6] 

> The "2.7" bit certainly looks fishy, as users should be able to
> choose between "2.6" and "2.7" (and possibly "3.0"), IIUC.
> +     PYTHON_PATH = /usr/pkg/bin/python2.7
> +     PERL_PATH = /usr/pkg/bin/perl

(I am one of the people who maintain the git package in pkgsrc.)

(Strictly, this is not really about NetBSD, but about all systems where
the standard approach to get python is via pkgsrc.  So that include
DragonflyBSD as well.  (pkgsrc runs on many other systems, but it isn't
the standard approach, so from the git viewpoint that's irrelevant.))

You are entirely right that on e.g. NetBSD 6 the view is that users
should be able to choose the python version.

pkgsrc can install multiple versions of python at the same time, to cope
with python-using packages that need different versions.  pkgsrc chooses
not to have a 'python' program, because that would result in installed
packages changing their binding of which python version to use when the
default was changed.  The default python version is currently 2.7, so
/usr/pkg/bin/python2.7 is the best guess for finding python on a NetBSD
system, if you're only allowed one guess.  A user can set a
PYTHON_VERSION_DEFAULT variable to choose the version they want; each
package expresses which versions will work.

This isn't relevant for git, not being a pure python library, but pkgsrc
supports installing multiple versions of some packages, so one can have
two versions installed at once:
  py27-expat-0nb6     Python interface to expat
  py26-expat-0nb6     Python interface to expat
The git package just depends on one version; by default the git package
depends on python (but one can tell it not to).

The python.m4 macro that comes with automake seems to find one of the
various pythonX.Y binaries in $PATH just fine.

pkgsrc has an entry for git (at
The key line for handling python is:
and there PYTHONBIN is set up by pkgsrc infrastructure for the right
prefix (99.9% but not always /usr/pkg) and version.  After this,
everything seems to come out right:

  > head -1 /usr/pkg/libexec/git-core/git-p4

So I'd say that if PYTHON_PATH is set in the environment to configure,
it should behave as it does now.  And if not, it would be nice if the
highest pythonX.Y found (that is known to work with git) is used.

> +     PYTHON_PATH = /usr/pkg/bin/python2.7
> +     PERL_PATH = /usr/pkg/bin/perl

So it would be nice to make these work as ?=, letting an environment
variable win if set.

Attachment: pgpTtVz1Ch_vc.pgp
Description: PGP signature

Reply via email to