pkg/42432: geography/gpsd configure no longer supports --disable-python, needs python dependency & magic

[kre%munnari.OZ.AU@localhost]

>Number:         42432
>Category:       pkg
>Synopsis:       geography/gpsd configure no longer supports --disable-python
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 09 13:15:01 +0000 2009
>Originator:     Robert Elz
>Release:        NetBSD 4.0 / i386  (pkgsrc current 2009-12-09)
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE 
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
        The most recent version of geography/gpsd (gpsd-2.90) no longer
        supports the --disable-python option to configure that was
        supported by the previous pkgsrc version (gpsd-2.38).  The
        Makefile still tries to tell configure --disable-python.
        Configure bitches, but ignores that.

        But, then, if no python is installed, configure fails (my
        reading of the configure script suggests that is not intended,
        and just not finding python is the way python is disabled,
        but as I build in a spartan sandbox, python would only be
        present if there was a dependency for it, and there isn't,
        and the package build failed.

        That's probably good, or we would have pkgsrc generating
        two different binary packages, depending upon whether python
        happened to be found in the build environment or not.
        That's not supposed to happen.

>How-To-Repeat:
        I use pkg_comp to get a nice clean sandbox to build in.
        It happens to have NetBSD 4.0 release sets installed,
        except the x* sets (I have X11_TYPE=modular), and it has
        libkver installed to simulate a 4.0 release kernel, but
        aside from the "clean sandbox" part, none of that is
        relevant here (start a build in a clean environment,
        which for this should be anything with no python, and
        you should see the same behaviour).


===> Configuring for gpsd-2.90
=> Modifying GNU configure scripts to avoid --recheck
=> Replacing config-guess with pkgsrc versions
=> Replacing config-sub with pkgsrc versions
=> Replacing install-sh with pkgsrc version
=> Checking for portability problems in extracted files
configure: WARNING: unrecognized options: --disable-python
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... /usr/bin/awk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for i386--netbsdelf-gcc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking how to run the C preprocessor... cc -E
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for a Python interpreter with version >= 2.4... none
configure: error: no suitable Python interpreter found
*** Error code 1

Stop.

>Fix:
        Sorry, python using packages are beyond me!

        Whether the right thing to do is bring back
        (at least the effect of) --disable-python to
        the configure script, or whether it now has so
        much python in it that it needs a dependency
        (and all the magic to work with various dfferent
        pythons??) someone else needs to determine.