[oe] [meta-oe][meta-networking][PATCH V2 3/3] ntp: Clean up recipes
Paul Eggleton
paul.eggleton at linux.intel.com
Sat Nov 10 13:22:53 UTC 2012
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
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-devel
mailing list