[MacPorts] #50288: UPDATE: gpsd-3.16
MacPorts
noreply at macports.org
Fri Feb 12 18:11:56 PST 2016
#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
More information about the macports-tickets
mailing list