[oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes

[Paul Eggleton]

On Friday 02 November 2012 09:07:43 Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
12.11.02 (Fri 09:59) Paul Eggleton wrote:
> > On Thursday 01 November 2012 13:32:40 Joe MacDonald wrote:
> > > Does it make sense to have both on a system?  That is, if you build
> > > ntp-ssl does that imply it will only use SSL for communications?  If
> > > that's not the case (which I suspect it isn't, but I haven't checked
> > > myself) then there's not really a strong reason to install both on the
> > > same system.  Which then seems fine to provide ntpdate-ssl as the
> > > alternative.
> > 
> > I'm not sure that it does. I think the split was made just to avoid
> > bringing in OpenSSL on systems where it was not needed or desired. Phil
> > Blundell (on CC) made the split quite a while ago in OE-Classic - Phil
> > can you comment?
>
> > > Now that I think about it a bit more, maybe a RPROVIDES is appropriate
> > > since ntp and ntpdate are overlapping in a lot of places.
> > 
> > Sorry, I don't quite understand what you mean here... ?
> 
> Sorry about that, I've been interleaving writing and thinking, usually
> not a good recipe.  :-)
> 
> It's been so long since I had to actually pay attention to what's in
> ntp that I'm just getting back clued up on it.  I was thinking that it
> should be made explicit in the ntp recipe that it provides ntpdate and
> therefore you would never need to have ntpdate and ntp/ntp-ssl installed
> on the same system at the same time.
> 
> So going back to Morgan's thing, I think now that the case of "add
> ntp-ssl and ntpdate" is invalid, and the result should be using ntp-ssl
> to provide ntpdate.  As long as that's what is happening with his
> recipe, I'm okay with it.  If it's actually dragging in ntp in addition
> to ntp-ssl purely to provide ntpdate, I think we have a problem.  And
> nothing should result in ntp[-ssl] and ntpdate (as in the things
> provided by two or more recipes) being on the same system at the same
> time, since ntp provides ntpdate anyway.  At least it looks like it does
> on my test build.

I have to say I think that these days this could be better implemented as one 
ntp recipe with a PACKAGECONFIG that you can use to enable OpenSSL support if 
desired. (At the time the ntp/ntp-ssl split was done, PACKAGECONFIG did not 
exist). Then it becomes a distro-level choice as to whether this is enabled as 
I believe was originally intended.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre