Re: [RFH] NetBSD 6?

Junio C Hamano [off-list ref] writes:

Greg Troxel [off-list ref] writes:

quoted

I realize a README.foo file for N different systems could be clutter,
but having these checked in would provide the concise help that people
on any of those platforms need.

Our Makefile documents knobs people on various platforms can tweak
(PYTHON_PATH and OLD_ICONV are two examples of them), sets default
values for them based on $(uname -S), then includes config.mak file
the user can optionally create to override these platform defaults.
This infrastructure is used across platforms, not just for NetBSD.

If you have to choose a single PYTHON_PATH, the one you picked is right
(for now, and likely will be right for a long time).

But as a general rule, I think configure tests are preferable to
OS-specific variables.

The part shown in the patch was to update the platform default for
NetBSD.  The setting we have been shipping in our Makefile seemed to
be different from what I needed on my NetBSD 6 install, and I was
wondering if we have no real users of Git on the platorm (which
would explain why we didn't get any complaints or patches to update
this part).  Or there are some optional packages all real NetBSD
users install, but being a NetBSD newbie I didn't, that makes the
values I showed in the patch inappropriate for them (e.g. Perhaps
there is a mechanism other than pkgsrc that installs perl and python
under /usr/bin?  Perhaps an optional libi18n package that gives
iconv(3) with new function signature?), in which case I definitely
should not apply that patch to my tree, as it would only be an
improvement for one person and a regression for existing users at
the same time.

A large number of people on NetBSD use git, but almost all of them get
it via pkgsrc (which is also where they get perl, emacs, svn, and
everything else you didn't find in /usr/bin).  The exception would be
people that want to hack on git itself.

People who want gnu libiconv can install the libiconv package from
pkgsrc.  (I'm guessing OLD_ICONV means "POSIX iconv", without GNU
extensions (iconvctl?).)  The git package doesn't depend on GNU iconv,
though (perhaps it should but we tend to avoid dependencies that arren't
really needed).

There are no mechanisms to install python/perl in /usr/bin, and doing so
would be viewed as bizarre.  /usr/bin belongs to the base system,
/usr/pkg to pkgsrc and /usr/local to the user.

So, it doesn't matter too much for pkgsrc what you change, because it
can be patched anyway (once, for all users).  It's probably better to
make a straightforward build from source come out right.
But, if the build respects the PYTHON_PATH environment variable, that's
easier (and more robust against changes) than patching.