[oe] [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa]

On Thu, Aug 28, 2014 at 10:23:54AM -0500, Peter A. Bigot wrote:
> On 08/28/2014 09:32 AM, Martin Jansa wrote:
> > On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
> >> On 08/28/2014 07:53 AM, Burton, Ross wrote:
> >>> On 28 August 2014 13:06, Peter A. Bigot <pab at pabigot.com> wrote:
> >>>> +PACKAGECONFIG ??= ""
> >>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
> >>> That's not actually deterministic - if pps-tools is installed but the
> >>> packageconfig option is disabled then gpsd will still enable the
> >>> support.
> >> Yeah, I'm aware of that.  It's also not something that can be
> >> controlled, since gpsd's author doesn't believe in configuration options
> >> to enable features: every capability is enabled or disabled by
> >> inspecting the environment at compile-time.
> >>
> >> Although ntp does support some explicit enable/disable flags, it too
> >> fails to provide a way to say "Pay no attention to that PPS header, it
> >> isn't really there."
> > Then we need to patch their configure.
> >
> >> For this situation I don't think there's a big issue.  The PACKAGECONFIG
> >> setting ensures that the header will be available if the feature is
> >> desired.  If it happens to be present but PPS support isn't explicitly
> >> requested, there's no failure in either build or runtime: it's still
> >> gated by runtime checks for PPS sources and the option being enabled in
> >> the Linux kernel.  (There are no runtime libraries that need to be
> >> installed to use KPPS.)
> >>
> >> Is this going to be a problem with the patch being accepted?
> > Yes
> >
> > people can be used to have KPPS support enabled by "accident" e.g.
> > because they are building ntp with KPPS support and pps-tools is almost
> > always built before gpsd..and then once it's built in different order and end-user will be
> > surprised by lost KPPS support from gpsd.
> 
> The number of people who will use KPPS is incredibly small, and nobody's 
> going to use it unintentionally as it requires on-target configuration.  
> Those who need it, though, have no recourse other than to build ntpd or 
> gpsd outside of OE if patches like these aren't present.
> 
> I understand the reasoning and agree in theory that absolute determinism 
> would be ideal, but believe hacking the ntp and gpsd configuration 
> infrastructure to explicitly disable use of a detected PPS header would 
> present a bigger risk and long-term cost to stability and 
> maintainability in OE than the possibility you've identified.  So that 
> solution isn't something I'm going to take on.
> 
> An alternative is to add kpps to the default PACKAGECONFIG, so the 
> required header is normally available.  The cost of the feature's 
> presence in the packages is nearly zero (a slight increase in daemon 
> code size, and an extra check when the process starts.)  Would that be 
> acceptable?

More acceptable than the undeterministic behavior - you should even add
it to DEPENDS.

> If we can't come to an agreement, then the only patch that's really 
> important is the first one which restores the ability to diagnose 
> misconfigured NTP systems.  Please let me know whether I should mark the 
> others as withdrawn in patchwork.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20140828/1ebb6701/attachment-0002.sig>