[oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
Joe MacDonald
Joe.MacDonald at windriver.com
Fri Nov 2 13:14:38 UTC 2012
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 14:09) Martin Ertsås wrote:
> 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 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.
> > 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 at 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.
Yep, my thoughts exactly.
--
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/5daad423/attachment-0002.sig>
More information about the Openembedded-devel
mailing list