[oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
Joe MacDonald
Joe.MacDonald at windriver.com
Fri Nov 2 14:02:23 UTC 2012
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> 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.
I'm also perfectly fine with that. Question, though. Do you mean that
the presence of OpenSSL in the distro would then mean you get ntp-ssl
all the time? That would be fine for me, but I wonder if anyone else
might want OpenSSL on their system but a non-ssl-enabled ntp? Probably
a silly case to be thinking about anyway.
I'm fine with a single recipe and using PACKAGECONFIG to control the
sslness of it.
--
Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River
direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20121102/a714af30/attachment-0002.sig>
More information about the Openembedded-devel
mailing list