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

login
register
mail settings
Submitter Morgan Little
Date Oct. 23, 2012, 4:20 p.m.
Message ID <1351009220-30119-4-git-send-email-morgan.little@windriver.com>
Download mbox | patch
Permalink /patch/38469/
State Accepted
Commit d102fc3fe64844f5c85ff350874728139a63fe78
Headers show

Comments

Morgan Little - Oct. 23, 2012, 4:20 p.m.
Clean up recipes to make them easier to read and to allow ntp-ssl to build
 * Move common portions to ntp.inc
 * Update ntp-ssl to require ntp.inc oppose to ntp_${PV}.bb
 * Change ntp-ssl EXTRA_OECONF to append so it won't try to configure snmp as
it will use local paths can cause a error while configuring

Signed-off-by: Morgan Little <morgan.little@windriver.com>
---
 .../recipes-support/ntp/ntp-ssl_4.2.6p5.bb         |   11 ++--
 meta-networking/recipes-support/ntp/ntp.inc        |   49 ++++++++++++++++++--
 meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb |   43 +-----------------
 3 files changed, 50 insertions(+), 53 deletions(-)
Paul Eggleton - Nov. 1, 2012, 1:08 a.m.
On Tuesday 23 October 2012 12:20:20 Morgan Little wrote: 
> -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
...
> +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"

I'm not particularly happy with this change. Apart from the fact that it 
wasn't mentioned in the commit message, it breaks any recipe that depends upon 
the previous ntpdate package. Could we go back to the old ntpdate name for the 
package or at the very least provide an RPROVIDES for the old name? I'm happy 
to submit a patch to do this once there is agreement either way.

Cheers,
Paul
Martin Ertsaas - Nov. 1, 2012, 5:50 a.m.
On 11/01/12 02:08, Paul Eggleton wrote:
> On Tuesday 23 October 2012 12:20:20 Morgan Little wrote:
>> -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
> ...
>> +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
> I'm not particularly happy with this change. Apart from the fact that it
> wasn't mentioned in the commit message, it breaks any recipe that depends upon
> the previous ntpdate package. Could we go back to the old ntpdate name for the
> package or at the very least provide an RPROVIDES for the old name? I'm happy
> to submit a patch to do this once there is agreement either way.
>
> Cheers,
> Paul
>
I agree with you. Also find it kind of strange to change from ntpdate to 
ntp-date, as the universally known name of that module is ntpdate. Don't 
really see the rational of changing that to ntp-date in the recipe.

- Martin
Joe MacDonald - Nov. 1, 2012, 2:31 p.m.
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 06:50) Martin Ertsås wrote:

> On 11/01/12 02:08, Paul Eggleton wrote:
> >On Tuesday 23 October 2012 12:20:20 Morgan Little wrote:
> >>-PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
> >...
> >>+PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
> >I'm not particularly happy with this change. Apart from the fact that it
> >wasn't mentioned in the commit message, it breaks any recipe that depends upon
> >the previous ntpdate package. Could we go back to the old ntpdate name for the
> >package or at the very least provide an RPROVIDES for the old name? I'm happy
> >to submit a patch to do this once there is agreement either way.
> >
> >Cheers,
> >Paul
> >
> I agree with you. Also find it kind of strange to change from
> ntpdate to ntp-date, as the universally known name of that module is
> ntpdate. Don't really see the rational of changing that to ntp-date
> in the recipe.

Agreed.  Though if there's a good reason to rename in ntp-date, that's
fine with me, so long as we go with Paul's suggestion of having an
RPROVIDES for ntpdate.  It's probably best to leave it as ntpdate,
though.
Morgan Little - Nov. 1, 2012, 5:09 p.m.
On 11/01/2012 10:31 AM, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.01 (Thu 06:50) Martin Ertsås wrote:
>
>> On 11/01/12 02:08, Paul Eggleton wrote:
>>> On Tuesday 23 October 2012 12:20:20 Morgan Little wrote:
>>>> -PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
>>> ...
>>>> +PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
>>> I'm not particularly happy with this change. Apart from the fact that it
>>> wasn't mentioned in the commit message, it breaks any recipe that depends upon
>>> the previous ntpdate package. Could we go back to the old ntpdate name for the
>>> package or at the very least provide an RPROVIDES for the old name? I'm happy
>>> to submit a patch to do this once there is agreement either way.
>>>
>>> Cheers,
>>> Paul
>>>
>> I agree with you. Also find it kind of strange to change from
>> ntpdate to ntp-date, as the universally known name of that module is
>> ntpdate. Don't really see the rational of changing that to ntp-date
>> in the recipe.
>
> Agreed.  Though if there's a good reason to rename in ntp-date, that's
> fine with me, so long as we go with Paul's suggestion of having an
> RPROVIDES for ntpdate.  It's probably best to leave it as ntpdate,
> though.
>
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.

//Morgan

> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Paul Eggleton - Nov. 1, 2012, 5:19 p.m.
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.

Cheers,
Paul
Joe MacDonald - Nov. 1, 2012, 5:32 p.m.
[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.
Martin Ertsaas - Nov. 2, 2012, 7 a.m.
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.

- Martin
Paul Eggleton - Nov. 2, 2012, 9:59 a.m.
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
Joe MacDonald - Nov. 2, 2012, 1:01 p.m.
[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.
Joe MacDonald - Nov. 2, 2012, 1:07 p.m.
[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.
Martin Ertsaas - Nov. 2, 2012, 1:09 p.m.
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
Joe MacDonald - Nov. 2, 2012, 1:14 p.m.
[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@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.

Yep, my thoughts exactly.
Paul Eggleton - Nov. 2, 2012, 1:38 p.m.
On Friday 02 November 2012 09:07:43 Joe MacDonald wrote:
> [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:
> > > 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.

I have to say I think that these days this could be better implemented as one 
ntp recipe with a PACKAGECONFIG that you can use to enable OpenSSL support if 
desired. (At the time the ntp/ntp-ssl split was done, PACKAGECONFIG did not 
exist). Then it becomes a distro-level choice as to whether this is enabled as 
I believe was originally intended.

Cheers,
Paul
Joe MacDonald - Nov. 2, 2012, 2:02 p.m.
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 13:38) Paul Eggleton wrote:

> On Friday 02 November 2012 09:07:43 Joe MacDonald wrote:
> > [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:
> > > > 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.
> 
> I have to say I think that these days this could be better implemented
> as one ntp recipe with a PACKAGECONFIG that you can use to enable
> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> choice as to whether this is enabled as I believe was originally
> intended.

I'm also perfectly fine with that.  Question, though.  Do you mean that
the presence of OpenSSL in the distro would then mean you get ntp-ssl
all the time?  That would be fine for me, but I wonder if anyone else
might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
a silly case to be thinking about anyway.

I'm fine with a single recipe and using PACKAGECONFIG to control the
sslness of it.
Paul Eggleton - Nov. 2, 2012, 2:10 p.m.
On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> > I have to say I think that these days this could be better implemented
> > as one ntp recipe with a PACKAGECONFIG that you can use to enable
> > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> > done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> > choice as to whether this is enabled as I believe was originally
> > intended.
> 
> I'm also perfectly fine with that.  Question, though.  Do you mean that
> the presence of OpenSSL in the distro would then mean you get ntp-ssl
> all the time?  That would be fine for me, but I wonder if anyone else
> might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
> a silly case to be thinking about anyway.

The idea with PACKAGECONFIG is it allows per-recipe control over this kind of 
thing. The default would be for OpenSSL support to be disabled, but it could 
be enabled with a bbappend containing PACKAGECONFIG += "openssl"; 
alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the 
distro .conf file or even local.conf.

I'll send a patch.

Cheers,
Paul
Joe MacDonald - Nov. 2, 2012, 2:14 p.m.
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 14:10) Paul Eggleton wrote:

> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> > On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> > > I have to say I think that these days this could be better implemented
> > > as one ntp recipe with a PACKAGECONFIG that you can use to enable
> > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> > > choice as to whether this is enabled as I believe was originally
> > > intended.
> > 
> > I'm also perfectly fine with that.  Question, though.  Do you mean that
> > the presence of OpenSSL in the distro would then mean you get ntp-ssl
> > all the time?  That would be fine for me, but I wonder if anyone else
> > might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
> > a silly case to be thinking about anyway.
> 
> The idea with PACKAGECONFIG is it allows per-recipe control over this kind of 
> thing. The default would be for OpenSSL support to be disabled, but it could 
> be enabled with a bbappend containing PACKAGECONFIG += "openssl"; 
> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the 
> distro .conf file or even local.conf.
> 
> I'll send a patch.

Great.  Thanks, Paul.
Phil Blundell - Nov. 2, 2012, 3:44 p.m.
On Fri, 2012-11-02 at 09:59 +0000, Paul Eggleton wrote:
> 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?

Yes, exactly.  If ntpdate is the only thing on the system that's linked
with openssl then it ends up dragging in several times its own weight in
dependencies.  And, for most people, having SSL-secured time is not that
much of a priority since the time server is typically on a trusted local
network.

p.
Paul Eggleton - Nov. 2, 2012, 5:26 p.m.
On Friday 02 November 2012 10:14:02 Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
12.11.02 (Fri 14:10) Paul Eggleton wrote:
> > On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> > > On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> > > > I have to say I think that these days this could be better implemented
> > > > as one ntp recipe with a PACKAGECONFIG that you can use to enable
> > > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> > > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> > > > choice as to whether this is enabled as I believe was originally
> > > > intended.
> > > 
> > > I'm also perfectly fine with that.  Question, though.  Do you mean that
> > > the presence of OpenSSL in the distro would then mean you get ntp-ssl
> > > all the time?  That would be fine for me, but I wonder if anyone else
> > > might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
> > > a silly case to be thinking about anyway.
> > 
> > The idea with PACKAGECONFIG is it allows per-recipe control over this kind
> > of thing. The default would be for OpenSSL support to be disabled, but it
> > could be enabled with a bbappend containing PACKAGECONFIG += "openssl";
> > alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the
> > distro .conf file or even local.conf.
> > 
> > I'll send a patch.
> 
> Great.  Thanks, Paul.

Unfortunately when I tested the OpenSSL part I found that it's not actually 
linking against the OpenSSL libraries (!) This is due to libssl and libcrypto 
being split between /usr/lib and /lib respectively instead of being in the 
same directory as the configure script expects. Also the OpenSSL include 
directory being specified does not match with what the configure script tests 
for (it's supposed to be the parent of the openssl directory, not the openssl 
directory itself).

I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin 
directory contains a bunch of binaries I would have assumed belonged in that 
package. What should be in these packages? Should there just be one?

Cheers,
Paul
Phil Blundell - Nov. 2, 2012, 9:09 p.m.
On Fri, 2012-11-02 at 13:38 +0000, Paul Eggleton wrote:
> I have to say I think that these days this could be better implemented as one 
> ntp recipe with a PACKAGECONFIG that you can use to enable OpenSSL support if 
> desired. (At the time the ntp/ntp-ssl split was done, PACKAGECONFIG did not 
> exist). Then it becomes a distro-level choice as to whether this is enabled as 
> I believe was originally intended.

Yes, agreed, that would be ideal.

p.
Joe MacDonald - Nov. 4, 2012, 6:43 p.m.
[Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote:

> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote:
> > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
> 12.11.02 (Fri 14:10) Paul Eggleton wrote:
> > > On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> > > > On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> > > > > I have to say I think that these days this could be better implemented
> > > > > as one ntp recipe with a PACKAGECONFIG that you can use to enable
> > > > > OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> > > > > done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> > > > > choice as to whether this is enabled as I believe was originally
> > > > > intended.
> > > > 
> > > > I'm also perfectly fine with that.  Question, though.  Do you mean that
> > > > the presence of OpenSSL in the distro would then mean you get ntp-ssl
> > > > all the time?  That would be fine for me, but I wonder if anyone else
> > > > might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
> > > > a silly case to be thinking about anyway.
> > > 
> > > The idea with PACKAGECONFIG is it allows per-recipe control over this kind
> > > of thing. The default would be for OpenSSL support to be disabled, but it
> > > could be enabled with a bbappend containing PACKAGECONFIG += "openssl";
> > > alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the
> > > distro .conf file or even local.conf.
> > > 
> > > I'll send a patch.
> > 
> > Great.  Thanks, Paul.
> 
> Unfortunately when I tested the OpenSSL part I found that it's not
> actually linking against the OpenSSL libraries (!) This is due to
> libssl and libcrypto being split between /usr/lib and /lib
> respectively instead of being in the same directory as the configure
> script expects.

Is that intentional?  I mean is that a misconfiguration or something
reasonably easily changed, or are there specific reasons for that split,
do you know?

> Also the OpenSSL include directory being specified does not match with
> what the configure script tests for (it's supposed to be the parent of
> the openssl directory, not the openssl directory itself).

Yeah, that's interesting.  Present in the existing recipe as well, from
what I can see, so I'm thinking that hasn't worked since at least the
update to 4.2.6p5.

Morgan, can you confirm that you've got SSL support working in your
updated recipe(s)?

> I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin 
> directory contains a bunch of binaries I would have assumed belonged in that 
> package. What should be in these packages? Should there just be one?

I think so.  Given that ntpd lives in FILES_${PN}, I'm thinking
everything listed in -bin looks appropriate for -utils.  Or dumping
-utils and leaving them in -bin.  Looking at the recipe it seems like
-utils was intended to be a housecleaning collection.  Did you find
other non-named binaries living in ${bindir} on some builds, Morgan?
Morgan Little - Nov. 9, 2012, 2:55 p.m.
On 11/04/2012 01:43 PM, Joe MacDonald wrote:
> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote:
>
>> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote:
>>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
>> 12.11.02 (Fri 14:10) Paul Eggleton wrote:
>>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
>>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
>>>>>> I have to say I think that these days this could be better implemented
>>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable
>>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
>>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level
>>>>>> choice as to whether this is enabled as I believe was originally
>>>>>> intended.
>>>>>
>>>>> I'm also perfectly fine with that.  Question, though.  Do you mean that
>>>>> the presence of OpenSSL in the distro would then mean you get ntp-ssl
>>>>> all the time?  That would be fine for me, but I wonder if anyone else
>>>>> might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
>>>>> a silly case to be thinking about anyway.
>>>>
>>>> The idea with PACKAGECONFIG is it allows per-recipe control over this kind
>>>> of thing. The default would be for OpenSSL support to be disabled, but it
>>>> could be enabled with a bbappend containing PACKAGECONFIG += "openssl";
>>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the
>>>> distro .conf file or even local.conf.
>>>>
>>>> I'll send a patch.
>>>
>>> Great.  Thanks, Paul.
>>
>> Unfortunately when I tested the OpenSSL part I found that it's not
>> actually linking against the OpenSSL libraries (!) This is due to
>> libssl and libcrypto being split between /usr/lib and /lib
>> respectively instead of being in the same directory as the configure
>> script expects.
>
> Is that intentional?  I mean is that a misconfiguration or something
> reasonably easily changed, or are there specific reasons for that split,
> do you know?
>
>> Also the OpenSSL include directory being specified does not match with
>> what the configure script tests for (it's supposed to be the parent of
>> the openssl directory, not the openssl directory itself).
>
> Yeah, that's interesting.  Present in the existing recipe as well, from
> what I can see, so I'm thinking that hasn't worked since at least the
> update to 4.2.6p5.
>
> Morgan, can you confirm that you've got SSL support working in your
> updated recipe(s)?
Looking at the configure output, it seems that my builds don't take ssl in either.
I'm not sure if 4.2.6p3 worked since without changes the old recipe doesn't build.

>
>> I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin 
>> directory contains a bunch of binaries I would have assumed belonged in that 
>> package. What should be in these packages? Should there just be one?
>
> I think so.  Given that ntpd lives in FILES_${PN}, I'm thinking
> everything listed in -bin looks appropriate for -utils.  Or dumping
> -utils and leaving them in -bin.  Looking at the recipe it seems like
> -utils was intended to be a housecleaning collection.  Did you find
> other non-named binaries living in ${bindir} on some builds, Morgan?
>
I didn't find any non-named binaries living in ${bindir}.

//Morgan
Joe MacDonald - Nov. 9, 2012, 3:04 p.m.
[RE: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.09 (Fri 09:55) Little, Morgan wrote:

> On 11/04/2012 01:43 PM, Joe MacDonald wrote:
> > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote:
> >
> >> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote:
> >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
> >> 12.11.02 (Fri 14:10) Paul Eggleton wrote:
> >>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> >>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> >>>>>> I have to say I think that these days this could be better implemented
> >>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable
> >>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> >>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> >>>>>> choice as to whether this is enabled as I believe was originally
> >>>>>> intended.
> >>>>>
> >>>>> I'm also perfectly fine with that.  Question, though.  Do you mean that
> >>>>> the presence of OpenSSL in the distro would then mean you get ntp-ssl
> >>>>> all the time?  That would be fine for me, but I wonder if anyone else
> >>>>> might want OpenSSL on their system but a non-ssl-enabled ntp?  Probably
> >>>>> a silly case to be thinking about anyway.
> >>>>
> >>>> The idea with PACKAGECONFIG is it allows per-recipe control over this kind
> >>>> of thing. The default would be for OpenSSL support to be disabled, but it
> >>>> could be enabled with a bbappend containing PACKAGECONFIG += "openssl";
> >>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl" in the
> >>>> distro .conf file or even local.conf.
> >>>>
> >>>> I'll send a patch.
> >>>
> >>> Great.  Thanks, Paul.
> >>
> >> Unfortunately when I tested the OpenSSL part I found that it's not
> >> actually linking against the OpenSSL libraries (!) This is due to
> >> libssl and libcrypto being split between /usr/lib and /lib
> >> respectively instead of being in the same directory as the configure
> >> script expects.
> >
> > Is that intentional?  I mean is that a misconfiguration or something
> > reasonably easily changed, or are there specific reasons for that split,
> > do you know?
> >
> >> Also the OpenSSL include directory being specified does not match with
> >> what the configure script tests for (it's supposed to be the parent of
> >> the openssl directory, not the openssl directory itself).
> >
> > Yeah, that's interesting.  Present in the existing recipe as well, from
> > what I can see, so I'm thinking that hasn't worked since at least the
> > update to 4.2.6p5.
> >
> > Morgan, can you confirm that you've got SSL support working in your
> > updated recipe(s)?
> Looking at the configure output, it seems that my builds don't take ssl in either.
> I'm not sure if 4.2.6p3 worked since without changes the old recipe doesn't build.

Yeah, that's expected based on Paul's findings.  I just meant could you
ensure it's working in the next version of the recipe update you send
out?  At some point in the past it was supposed to work, we should
probably try to get back there.  :-)

> >> I've also noticed that the ${PN}-utils package ends up empty and the ${PN}-bin 
> >> directory contains a bunch of binaries I would have assumed belonged in that 
> >> package. What should be in these packages? Should there just be one?
> >
> > I think so.  Given that ntpd lives in FILES_${PN}, I'm thinking
> > everything listed in -bin looks appropriate for -utils.  Or dumping
> > -utils and leaving them in -bin.  Looking at the recipe it seems like
> > -utils was intended to be a housecleaning collection.  Did you find
> > other non-named binaries living in ${bindir} on some builds, Morgan?
> >
> I didn't find any non-named binaries living in ${bindir}.

Okay, so dump one of -utils or -bin, I'm leaning toward keeping the
former and dumping the latter, but that's really up to you.
Paul Eggleton - Nov. 10, 2012, 1:22 p.m.
On Friday 09 November 2012 10:04:14 Joe MacDonald wrote:
> [RE: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes] On 
12.11.09 (Fri 09:55) Little, Morgan wrote:
> > On 11/04/2012 01:43 PM, Joe MacDonald wrote:
> > > [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up 
recipes] On 12.11.02 (Fri 17:26) Paul Eggleton wrote:
> > >> On Friday 02 November 2012 10:14:02 Joe MacDonald wrote:
> > >>> [Re: [oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up
> > >>> recipes] On> >> 
> > >> 12.11.02 (Fri 14:10) Paul Eggleton wrote:
> > >>>> On Friday 02 November 2012 10:02:23 Joe MacDonald wrote:
> > >>>>> On 12.11.02 (Fri 13:38) Paul Eggleton wrote:
> > >>>>>> I have to say I think that these days this could be better
> > >>>>>> implemented
> > >>>>>> as one ntp recipe with a PACKAGECONFIG that you can use to enable
> > >>>>>> OpenSSL support if desired. (At the time the ntp/ntp-ssl split was
> > >>>>>> done, PACKAGECONFIG did not exist). Then it becomes a distro-level
> > >>>>>> choice as to whether this is enabled as I believe was originally
> > >>>>>> intended.
> > >>>>> 
> > >>>>> I'm also perfectly fine with that.  Question, though.  Do you mean
> > >>>>> that
> > >>>>> the presence of OpenSSL in the distro would then mean you get
> > >>>>> ntp-ssl
> > >>>>> all the time?  That would be fine for me, but I wonder if anyone
> > >>>>> else
> > >>>>> might want OpenSSL on their system but a non-ssl-enabled ntp? 
> > >>>>> Probably
> > >>>>> a silly case to be thinking about anyway.
> > >>>> 
> > >>>> The idea with PACKAGECONFIG is it allows per-recipe control over this
> > >>>> kind
> > >>>> of thing. The default would be for OpenSSL support to be disabled,
> > >>>> but it
> > >>>> could be enabled with a bbappend containing PACKAGECONFIG +=
> > >>>> "openssl";
> > >>>> alternatively you could do PACKAGECONFIG_append_pn-ntp = " openssl"
> > >>>> in the
> > >>>> distro .conf file or even local.conf.
> > >>>> 
> > >>>> I'll send a patch.
> > >>> 
> > >>> Great.  Thanks, Paul.
> > >> 
> > >> Unfortunately when I tested the OpenSSL part I found that it's not
> > >> actually linking against the OpenSSL libraries (!) This is due to
> > >> libssl and libcrypto being split between /usr/lib and /lib
> > >> respectively instead of being in the same directory as the configure
> > >> script expects.
> > > 
> > > Is that intentional?  I mean is that a misconfiguration or something
> > > reasonably easily changed, or are there specific reasons for that split,
> > > do you know?
> > > 
> > >> Also the OpenSSL include directory being specified does not match with
> > >> what the configure script tests for (it's supposed to be the parent of
> > >> the openssl directory, not the openssl directory itself).
> > > 
> > > Yeah, that's interesting.  Present in the existing recipe as well, from
> > > what I can see, so I'm thinking that hasn't worked since at least the
> > > update to 4.2.6p5.
> > > 
> > > Morgan, can you confirm that you've got SSL support working in your
> > > updated recipe(s)?
> > 
> > Looking at the configure output, it seems that my builds don't take ssl in
> > either. I'm not sure if 4.2.6p3 worked since without changes the old
> > recipe doesn't build.
> Yeah, that's expected based on Paul's findings.  I just meant could you
> ensure it's working in the next version of the recipe update you send
> out?  At some point in the past it was supposed to work, we should
> probably try to get back there.  :-)
> 
> > >> I've also noticed that the ${PN}-utils package ends up empty and the
> > >> ${PN}-bin directory contains a bunch of binaries I would have assumed
> > >> belonged in that package. What should be in these packages? Should
> > >> there just be one?> > 
> > > I think so.  Given that ntpd lives in FILES_${PN}, I'm thinking
> > > everything listed in -bin looks appropriate for -utils.  Or dumping
> > > -utils and leaving them in -bin.  Looking at the recipe it seems like
> > > -utils was intended to be a housecleaning collection.  Did you find
> > > other non-named binaries living in ${bindir} on some builds, Morgan?
> > 
> > I didn't find any non-named binaries living in ${bindir}.
> 
> Okay, so dump one of -utils or -bin, I'm leaning toward keeping the
> former and dumping the latter, but that's really up to you.

FYI I am still working on a patch for the ntp recipes here but have yet to fix 
the SSL issue fully.

Cheers,
Paul

Patch

diff --git a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb
index a158990..e5851ae 100644
--- a/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb
+++ b/meta-networking/recipes-support/ntp/ntp-ssl_4.2.6p5.bb
@@ -1,11 +1,10 @@ 
-require ntp_${PV}.bb
+require ntp.inc
 DEPENDS = "openssl"
 
 S = "${WORKDIR}/ntp-${PV}"
 
-EXTRA_OECONF = "--with-openssl-libdir=${STAGING_LIBDIR} \
-	        --with-openssl-incdir=${STAGING_INCDIR}/openssl"
+EXTRA_OECONF += "--with-openssl-libdir=${STAGING_LIBDIR} \
+		 --with-openssl-incdir=${STAGING_INCDIR}/openssl \
+		 --with-crypto"
 
-
-SRC_URI[md5sum] = "98e16c7aa4ecd4c004b51bff18962e95"
-SRC_URI[sha256sum] = "9f4a5271a285d390c9225e3ea28f70049ea377d30fc6de4659007cfff278671a"
+FILES_${PN} += "${bindir}/sntp ${bindir}/ntp-keygen"
diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc
index 1d740f0..e2dbdad 100644
--- a/meta-networking/recipes-support/ntp/ntp.inc
+++ b/meta-networking/recipes-support/ntp/ntp.inc
@@ -8,14 +8,19 @@  LICENSE = "ntp"
 LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670"
 RSUGGESTS_${PN} = "iana-etc"
 
-SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/${P}.tar.gz \
-	file://ipv6only-workaround.patch \
+INC_PR = "r1"
+
+SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
+	file://tickadj.c.patch \
+	file://ntp-4.2.4_p6-nano.patch \
 	file://ntpd \
 	file://ntp.conf \
 	file://ntpdate \
-	file://ntpd.service \
 "
 
+SRC_URI[md5sum] = "00df80a84ec9528fcfb09498075525bc"
+SRC_URI[sha256sum] = "d6ab8371f9d31e594eb6922823d5ccd03dcc4e9d84b0e23ea25ac1405432f91c"
+
 inherit autotools update-rc.d
 
 INITSCRIPT_NAME = "ntpd"
@@ -24,12 +29,46 @@  INITSCRIPT_PARAMS = "defaults"
 
 # The ac_cv_header_readline_history is to stop ntpdc depending on either
 # readline or curses
-EXTRA_OECONF = "--without-openssl --without-crypto ac_cv_header_readline_history_h=no"
+EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd ac_cv_header_readline_history_h=no"
 CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED"
 
-PACKAGES += "ntpdate ${PN}-bin ${PN}-tickadj ${PN}-utils"
+do_configure(){
+	oe_runconf
+}
+
+do_install_append() {
+	install -d ${D}/${sysconfdir}/init.d
+	install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir}
+	install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d
+	install -d ${D}/${sysconfdir}/network/if-up.d
+	install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d
+}
+
+FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace"
+FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd ${sbindir} ${libdir}"
+FILES_${PN}-tickadj = "${bindir}/tickadj"
+FILES_${PN}-utils = "${bindir}/*"
+FILES_${PN}-date += "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate"
+
+# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms
+# with wonky clocks (e.g. OpenSlug)
+RDEPENDS_${PN} = "${PN}-tickadj"
+
+PACKAGES += "${PN}-date ${PN}-bin ${PN}-tickadj ${PN}-utils"
 # NOTE: you don't need ntpdate, use "ntpd -q -g -x"
 # or the ntpdate systemd service
 
 # This should use rc.update
 FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/init.d/ntpdate"
+
+pkg_postinst_ntpdate() {
+if test "x$D" != "x"; then
+        exit 1
+else
+        if ! grep -q -s ntpdate /var/spool/cron/root; then
+                echo "adding crontab"
+                test -d /var/spool/cron || mkdir -p /var/spool/cron
+                echo "30 * * * *    /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root
+        fi
+fi
+}
diff --git a/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb
index f7c5b68..175a1b0 100644
--- a/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb
+++ b/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb
@@ -1,45 +1,4 @@ 
 require ntp.inc
 
-SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
-        file://tickadj.c.patch \
-        file://ntp-4.2.4_p6-nano.patch \
-        file://ntpd \
-        file://ntp.conf \
-        file://ntpdate \
-"
-
-SRC_URI[md5sum] = "59876a9009b098ff59767ee45a88ebd2"
-SRC_URI[sha256sum] = "6e84d4ddfa14b911c3ed88463af10867e1fa9b287e7b34d8a02e78be85a7c40e"
-
-EXTRA_OECONF += " --with-net-snmp-config=no --without-ntpsnmpd" 
-
-do_install_append() {
-	install -d ${D}/${sysconfdir}/init.d
-	install -m 644 ${WORKDIR}/ntp.conf ${D}/${sysconfdir}
-	install -m 755 ${WORKDIR}/ntpd ${D}/${sysconfdir}/init.d
-	install -d ${D}/${sysconfdir}/network/if-up.d
-	install -m 755 ${WORKDIR}/ntpdate ${D}/${sysconfdir}/network/if-up.d
-}
-
-FILES_${PN}-bin = "${bindir}/ntp-wait ${bindir}/ntpdc ${bindir}/ntpq ${bindir}/ntptime ${bindir}/ntptrace"
-FILES_${PN} = "${bindir}/ntpd ${sysconfdir}/ntp.conf ${sysconfdir}/init.d/ntpd"
-FILES_${PN}-tickadj = "${bindir}/tickadj"
-FILES_ntp-utils = "${bindir}/*"
-FILES_ntpdate = "${bindir}/ntpdate ${sysconfdir}/network/if-up.d/ntpdate"
-
-# ntp originally includes tickadj. It's split off for inclusion in small firmware images on platforms
-# with wonky clocks (e.g. OpenSlug)
-RDEPENDS_${PN} = "${PN}-tickadj"
-
-pkg_postinst_ntpdate() {
-if test "x$D" != "x"; then
-        exit 1
-else
-        if ! grep -q -s ntpdate /var/spool/cron/root; then
-                echo "adding crontab"
-                test -d /var/spool/cron || mkdir -p /var/spool/cron
-                echo "30 * * * *    /usr/bin/ntpdate -b -s -u pool.ntp.org" >> /var/spool/cron/root
-        fi
-fi
-}
+EXTRA_OECONF += "--without-openssl --without-crypto"