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

[Joe MacDonald <Joe.MacDonald@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

[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?

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]