[MacPorts] #50288: UPDATE: gpsd-3.16

MacPorts

11 Jan 2016 11 Jan '16

12:23 a.m.

#50288: UPDATE: gpsd-3.16 --------------------+-------------------------------- Reporter: fw@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: gpsd --------------------+-------------------------------- This is just a placeholder for now. I'm in the process of testing a 3.16 port, and will upload files when ready. -- Ticket URL: <https://trac.macports.org/ticket/50288> MacPorts <https://www.macports.org/> Ports system for OS X

Show replies by date

MacPorts

20 Jan 20 Jan

6:37 a.m.

#50288: UPDATE: gpsd-3.16 ---------------------+-------------------------------- Reporter: fw@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: gpsd | ---------------------+-------------------------------- Comment (by fw@…): Here are the files for the 3.16 port. I supplied both a diff of the Portfile against the previous published version, and the complete new Portfile, which is more readable (and smaller). The patch files are presented as is, rather than readability-challenged diffs of diffs, and I also included a complete tarball of all the files with correct timestamps (though the repository doesn't seem to be set up to preserve timestamps). Changes from a file perspective: The two pc.in patchfiles are obsoleted by upstream fixes, and have been removed. The two remaining code patchfiles have been updated to match the updated sources, but are functionally unchanged (other than adding a comment line to the rtcm2 patch to clarify why the order matters). The SConstruct patchfile has been updated both because of substantial upstream changes to SConstruct since 3.14, and to add a couple of tweaks. The Portfile has changed substantially. Changes from a functional perspective: The universal variant has been disabled, since it didn't work (and would probably require significant work on the SConstruct script to implement). A new "xgps" variant has been added to determine whether the xgps and xgpsspeed X11 programs are included. This is because they both require gobject and gtk, expanding recursively to over 150 (previously unexpressed) dependencies that aren't otherwise needed. This is plumbed via a new SConstruct option. There are now three Qt-related variants - qt4, qt5, and qt. The first two build against the specified Qt version, and the last is equivalent to whichever qtN variant is appropriate for the OS version. This is qt4 for OSX < 10.8 and qt5 for OSX >= 10.8, corresponding (mostly) to the Qt5 supported OS list. Qt5 doesn't consider 10.11 to be a supported OS, but this is presumably temporary, and isn't reflected in the selection. This is similar to what was suggested in #47739, though with a more aggressive move to Qt5. Since the only Qt module used here is QtNetwork, and since none of the items listed as incompatible changes in QtNetwork appears to be used, it's reasonable to expect that the Qt5 substitution will work without any code changes. However, the name change from QtNetwork to Qt5Network required adding a new option to SConstruct. There's a workaround for #50347 in the Qt4 setup. The variants now correctly control the build options and the dependencies, which wasn't entirely the case previously. The "LIBPATH='.'" arguments in the SConstruct script, which only served to break linking against libdbus-1, have been patched out. The test phase is now implemented, running all the provided regression tests (with a hack to keep them from being ridiculously slow - see the comment). Because 3.16 changes all the Python shebang lines to refer to "python2", this now explicitly depends on python2_select, and includes both a note to suggest using it if "python2" isn't found in the command path, and a similar fatal error at the start of the test phase (since the tests require "python2"). The bad permissions on gpsprof (in the 3.16 release tarball) are corrected. The long description has been expanded and cosmetically cleaned up. Testing: Build/installs have been tested for no variants, maximal variants, and the non-default Qt variant, as well as running the regression tests. This was done on a Mac Pro running 10.9.5, a PowerBook running 10.5.8, and x86_64 VMs running all OS versions from 10.5 through 10.11. The Qt5 builds failed on 10.5 and 10.6, due to the Qt5 build itself (intentionally) failing, but everything else worked. Note that Qt wasn't tested beyond testing the builds, since there aren't any Qt tests included. -- Ticket URL: <https://trac.macports.org/ticket/50288#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X

MacPorts

24 Jan 24 Jan

7:57 p.m.

MacPorts

8:19 p.m.

MacPorts

2 Feb 2 Feb

8:52 p.m.

MacPorts

11 Feb 11 Feb

10:03 a.m.

MacPorts

9:01 p.m.

...

Wow, that's great work! Just a small nitpick: there's no need to explicitly depend on python2_select since python2.7 has a runtime dependency on it. With that corrected I'll happily commit it.

I thought about that, but I disagree, since I think it's bad practice to rely on an indirect dependency for something which is a direct requirement. For example, if I have a C program that uses something in foo.h, it will of course include foo.h. If foo.h needs something from bar.h, it will include bar.h. But if my code also *directly* uses something from bar.h, then it should also include bar.h explicitly, rather than relying on the internal include within foo.h. In this case, since the Python {{{gpsd}}} code needs a {{{python2}}} command, it's appropriate for it to explicitly depend on {{{python2_select}}} (which is imperfect in that it doesn't guarantee that {{{python2_select}}} has been *used*, but it's the best we can do with dependencies). And strictly speaking, there's no reason in principle why {{{python27}}} needs a dependency on {{{python2_select}}}, since it probably has no {{{python2}}} commands of its own. That dependency is presumably only there for convenience, given that it's fairly inexpensive, making it particularly dangerous to rely on it. Once {{{gpsd}}}'s Python code has been updated to be compatible with Python 3, the {{{python2}}} issue will become moot.

...

Another thing: if you {{{cd}}} in the port directory and run {{{svn diff port.patch}}} svn should output a patch of everything in one, making applying it easier.

I've attached a diff of that form. -- Ticket URL: <https://trac.macports.org/ticket/50288#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X

MacPorts

9:13 p.m.

MacPorts

10:15 p.m.

...

While what you say about `bar.h` is true, depending on `python2_select` doesn't guarantee you in any way that the `python2` command exists.

Hence the (dynamically conditional) `port notes` when it doesn't (and the error if one tries to run `port test` without `python2`).

...

The package needs to `reinplace` the lines calling `python2` with `${prefix}/bin/python2.7`. You should not ask users to run `port select python2` manually.

While I agree that that would be more convenient for users that haven't previously used `port select python2`, it does have some disadvantages: 1) It requires patching 8 more files that otherwise don't need it. I'm trying to *reduce* the number of MacPorts-specific patches, not increase it. :-) 2) It unnecessarily breaks the ability to use Python 2.6. The only reason I made the port dependency specifically on `python27` is that I didn't want to go to the trouble of creating Python version variants (and also that the required `scons` port depends specifically on `python27`, presumably for a similar reason); the code itself will work just fine if `python2` maps to `python26`. 3) Any user interested in `PEP0394` compliance should run `port select python2`, anyway. -- Ticket URL: <https://trac.macports.org/ticket/50288#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X

MacPorts

12 Feb 12 Feb

9:40 a.m.

#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 mojca@…): I do sympathize with this to some extent, but it's against the policy and general practice of most other ports. 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 } } }}} 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. I would suggest you to raise the question on the `macports-dev` mailing list and ask other developers for opinion. -- Ticket URL: <https://trac.macports.org/ticket/50288#comment:10> MacPorts <https://www.macports.org/> Ports system for OS X

MacPorts

13 Feb 13 Feb

2:11 a.m.

...

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

MacPorts

8:32 a.m.

MacPorts

10 May 10 May

3:25 p.m.

MacPorts

16 May 16 May

10:59 p.m.

#50288: UPDATE: gpsd-3.16 ---------------------+-------------------------- Reporter: fw@… | Owner: ryandesign@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: gpsd | ---------------------+-------------------------- Changes (by ryandesign@…): * status: new => assigned -- Ticket URL: <https://trac.macports.org/ticket/50288#comment:15> MacPorts <https://www.macports.org/> Ports system for OS X

3464

Age (days ago)

3590

Last active (days ago)

List overview

Download

13 comments

1 participants

participants (1)

MacPorts

[MacPorts] #50288: UPDATE: gpsd-3.16

tags

participants (1)