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

["Martin Ertsås" <martiert@gmail.com>]

On 11/02/12 14:01, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 08:00) Martin Ertsås wrote:
>
>> 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@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.
> Yeah, exactly.  The only time I've ever wanted both ntp and ntpdate on
> the same system at the same time was when I had a system with a clock
> that was so badly damaged occasionally ntp couldn't recover it and I
> needed to just do a reset on the time.  But I could have even
> accomplished that with ntp -q.  In fact, a quick check of the ntp
> manpage on my system says:
>
>        -q     Exit the ntpd just after the first time the clock is set.
>               This behavior mimics that of the ntpdate  program, which
>               is to be retired.  The -g and -x options can be used with
>               this option.  Note: The kernel time discipline is disabled
>               with this option.
>
> So I'm thinking that ntpdate can be completely replaced with ntp if
> you're putting that on your system.  The obvious fallout would be in any
> scripts specifically relying on something called 'ntpdate', but it looks
> to me like the ntp package is already providing an ntpdate binary.
> Seeing that, it seems to me that ntp/ntp-ssl and ntpdate actually
> conflict with each other.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Then I agree, and think a nice solution to this would be that ntp
provides ntpdate, as we don't want both. If you install ntp, you won't
need ntpdate, and if you want ntpdate, you don't need all of ntp, and
therefor just install ntpdate, and the same goes of course if what you
want is ntp-ssl.

If ntp is actually providing a ntpdate binary, I agree that it should
actually conflict, and not only provide ntpdate.

- Martin