[MacPorts] #50288: UPDATE: gpsd-3.16

[MacPorts]

#50288: UPDATE: gpsd-3.16
---------------------+--------------------------
  Reporter:  fw@…    |      Owner:  ryandesign@…
      Type:  update  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  haspatch
      Port:  gpsd    |
---------------------+--------------------------

Comment (by fw@…):

 Replying to [comment:10 mojca@…]:
 > I do sympathize with this to some extent, but it's against the policy
 and general practice of most other ports.

 It's difficult to quantify "most" without some fairly painstaking
 analysis, but it's certainly not "all".

 > Running `reinplace` is simple enough and doesn't require writing
 explicit patches. For example:
 > {{{
 > fs-traverse f ${worksrcpath} {
 >     if {[string match "*.py" "$f"]} {
 >         reinplace "s|/usr/bin/env python2|${python_bin}|" $f
 >     }
 > }
 > }}}

 A patch is still a patch, whether it's by a patchfile or inline in the
 Portfile.  Every patch makes the port harder to maintain by requiring more
 analysis to move to a new upstream version.  As it is (since I've now
 gotten most of the patches incorporated upstream), there's a fairly good
 chance that by the time 3.17 is released, it can be completely patch-free,
 and I'd prefer to keep it that way.

 Not to mention all the testing (see above) that I'd have to redo if I
 changed anything. :-)

 > On top of that, if the user indeed picked python2.6 with `port select`
 and `gpsd` depends on `py-pygtk`, but the port only installed
 `py27-pygtk`, it will fail to work because the port doesn't guarantee in
 any way that `py26-pygtk` is present. Worse yet, let's assume that user
 has selected `port select python2`, but has another instance of `python2`
 binary that comes before python provided by MacPorts. It would fail just
 as well because that other `python2` won't have the required dependencies.

 That's no different from what happens with a program that specifies
 `python` and one does a `port select python` without having the required
 dependencies.  And putting another `python` or `python2` ahead of the
 MacPorts position in the command path breaks the corresponding selector
 entirely, regardless of which one it is.  So none of that has anything to
 do with `python2` vs. `python`.

 Just among the ports I have installed here, I count 13 non-`gpsd`
 executables specifying the generic `python` in the shebang line (which is
 fine by those of us who find gratuitous monoversionism annoying).  Up
 through version 3.15, `gpsd` also used the generic `python` in all its
 shebang lines.  It changed them to `python2` in 3.16 because at least one
 Linux distro has switched to Python3 as the default Python, and the code
 isn't Python3-ready.  The only *real* difference between `python2` and
 `python` is that Apple provides the latter regardless of MacPorts, while
 the former is missing from a base install.

 Assuming `/usr/local/bin` exists and is in the command path, then `sudo ln
 -s /usr/bin/python /usr/local/bin/python2` is sufficient to make `python2`
 shebang lines work just as well as `python` shebang lines in all cases (at
 least until such time as Apple moves to a Python3 default, which hasn't
 happened yet, and which ought to be accompanied by a proper `python2` if
 and when it happens).  It's not a bad idea to do that for consistency
 anyway, regardless of what one does with `python2_select`, but I thought
 it was best to warn users who hadn't set up any form of `python2` (though
 some `gpsd` users might not even care about the Python components; it's
 primarily a C package).

 Although `gpsd` may be the first port where this issue has appeared (or at
 least the first one where anyone has noticed), it's almost certainly not
 the last, as additional non-Python3-ready code gets tweaked to defend
 against Python3 as the default.  Does it really make sense to inflict a
 growing number of maintainability-reducing patches on a growing number of
 ports, just to let some subset of users avoid a one-time use of a one-line
 command that they should probably be doing anyway?

 BTW, it would probably be a good idea to expand the port notes for the
 Python 2.x ports to suggest using `port select python2`, in addition to
 the current suggestion for `port select python` (given the likely future
 increase in the use of `python2`).  If that had been in place for a while,
 I wouldn't have bothered doing anything about it here.

-- 
Ticket URL: <https://trac.macports.org/ticket/50288#comment:11>
MacPorts <https://www.macports.org/>
Ports system for OS X