Re: [RFH] NetBSD 6?

From: Greg Troxel <gdt@ir.bbn.com>
Date: Jan 3, 2013, 13:58 UTC
Message-ID: <rmi8v8av05d.fsf@fnord.ir.bbn.com>
In-Reply-To: <7vd2xnypt6.fsf@alter.siamese.dyndns.org>

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

Show 11 quoted lines

> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> 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.

Show 14 quoted lines

> 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.