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

[Paul Eggleton <paul.eggleton@linux.intel.com>]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre