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: 4239 bytes --]

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

-- 
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 --]