Re: [RFH] NetBSD 6?

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

(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 1.8.0.1).
The key line for handling python is:
  MAKE_FLAGS+=	PYTHON_PATH=${PYTHONBIN}
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
  #!/usr/pkg/bin/python2.7

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.

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