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

Martin Ertsås martiert at gmail.com
Fri Nov 2 07:00:09 UTC 2012


On 11/01/12 18:32, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 17:19) Paul Eggleton wrote:
>
>> On Thursday 01 November 2012 17:09:59 Little, Morgan wrote:
>>> My rational behind splitting like that is if it is just ntpdate and you try
>>> to add ntp-ssl and ntpdate it will use ntp to provide ntpdate. It could be
>>> change add RPROVIDES so ntp will provide ntpdate and ntp-ssl provides a
>>> uniquely named version.
>> The ssl version could be ntpdate-ssl if it needs to be unique. I think 
>> originally though these recipes weren't intended to be built side-by-side - 
>> rather they were mutually exclusive and the distro would make a choice as to 
>> which one was built.
> Hmm, good point.
>
> 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.
>
> 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.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Are you thinking of ntp providing ntpdate then? In my mind at least,
this makes sense, as ntp seems able to do whatever ntpdate does, so I
don't really see the rational of having both on the same system.

- Martin



More information about the Openembedded-devel mailing list