Re: gpsd on the way to 2.91; gps_poll non-blocking
Hi,
>> gaia: Will NMU tonight.
Sitting in delayed/2 since ~12 hours.
>> geoclue: needs a bit larger patch as there is some weird code in it.
>> Working on that.
>
>> kde*: fixed in svn, waiting for an upload afaik.
>
> kde* has been fixed (it builds, but not sure if works :/) and uploaded.
The patch looks good. I've just uploaded a svn snapshot which fixes an issue in
libgps, so with that everything should be fine.
>> navit: patch provided by me, should be fixed soon.
>> s3d: fixed.
>> viking: fixed.
>>
>> With gpsd 2.91 (and the svn snapshot I'll upload soon to fix a different
>> bug) gps_poll will *not* block any more. As this is a change programs will
>> start to rely on soon it might make sense to bump the -dev package now,
>> but as the number of rdeps is very limited it should be enough to use
>> autotools and friends to check for the right package version.
>
> At least according to [1], this is going to be optional & non-default
> behaviour, so maybe it is not that important (and scary) after all? If not, I
> hope there will be a guide how to fix this yet another API incompatibility.
>
> 1. http://svn.berlios.de/viewvc/gpsd?view=rev&revision=6770
Ok, then it is not an API incompatibility, gps_poll still works as before by
default. But even when it would be non-blocking by default, properly coded
programs should just be fine as they're not supposed to assume that there is
information available in the gpsdata struct. gps_poll being non-blocking just
makes it more simple to use.
Cheers,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Reply to: