#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