From: Joe MacDonald <Joe.MacDonald@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: "Little, Morgan" <Morgan.Little@windriver.com>,
openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
Date: Fri, 2 Nov 2012 09:07:43 -0400 [thread overview]
Message-ID: <20121102130743.GC4416@windriver.com> (raw)
In-Reply-To: <2240810.9tyY23JxNH@helios>
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
[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:
> > [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... ?
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.
--
Joe MacDonald, Sr. Member of Technical Staff, Linux Products Group, Wind River
direct 613.270.5750 mobile 613.291.7421 fax 613.592.2283
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2012-11-02 13:21 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
2012-11-02 13:07 ` Joe MacDonald [this message]
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=20121102130743.GC4416@windriver.com \
--to=joe.macdonald@windriver.com \
--cc=Morgan.Little@windriver.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.