From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: openembedded-devel@lists.openembedded.org
Cc: "Little, Morgan" <Morgan.Little@windriver.com>,
Joe MacDonald <Joe.MacDonald@windriver.com>
Subject: Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
Date: Fri, 02 Nov 2012 09:59:16 +0000 [thread overview]
Message-ID: <2240810.9tyY23JxNH@helios> (raw)
In-Reply-To: <20121101173240.GV4673@windriver.com>
On Thursday 01 November 2012 13:32:40 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.
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... ?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-11-02 10:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 16:20 [meta-oe][meta-networking][PATCH V2 0/3] ntp updates Morgan Little
2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 1/3] ntp: Move from meta-oe to meta-networking Morgan Little
2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 2/3] ntp: Uprev from 4.2.6p3 to 4.2.6p5 Morgan Little
2012-10-23 16:20 ` [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes Morgan Little
2012-11-01 1:08 ` Paul Eggleton
2012-11-01 5:50 ` Martin Ertsås
2012-11-01 14:31 ` Joe MacDonald
2012-11-01 17:09 ` Little, Morgan
2012-11-01 17:19 ` Paul Eggleton
2012-11-01 17:32 ` Joe MacDonald
2012-11-02 7:00 ` Martin Ertsås
2012-11-02 13:01 ` Joe MacDonald
2012-11-02 13:09 ` Martin Ertsås
2012-11-02 13:14 ` Joe MacDonald
2012-11-02 9:59 ` Paul Eggleton [this message]
2012-11-02 13:07 ` Joe MacDonald
2012-11-02 13:38 ` Paul Eggleton
2012-11-02 14:02 ` Joe MacDonald
2012-11-02 14:10 ` Paul Eggleton
2012-11-02 14:14 ` Joe MacDonald
2012-11-02 17:26 ` Paul Eggleton
2012-11-04 18:43 ` Joe MacDonald
2012-11-09 14:55 ` Little, Morgan
2012-11-09 15:04 ` Joe MacDonald
2012-11-10 13:22 ` Paul Eggleton
2012-11-02 21:09 ` Phil Blundell
2012-11-02 15:44 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2240810.9tyY23JxNH@helios \
--to=paul.eggleton@linux.intel.com \
--cc=Joe.MacDonald@windriver.com \
--cc=Morgan.Little@windriver.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox