[OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version

[Khem Raj]

we are good with fixes in master-next
On Mon, Sep 10, 2018 at 10:54 AM Andre McCurdy <armccurdy at gmail.com> wrote:
>
> On Wed, Sep 5, 2018 at 8:55 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> > https://wiki.debian.org/OpenSSL-1.1 says it will cause runtime bugs like
> > segmentation faults or just misbehaving applications.
> >
> > On Wed, Sep 5, 2018 at 5:45 PM Andre McCurdy <armccurdy at gmail.com> wrote:
> >>
> >> On Wed, Sep 5, 2018 at 8:15 AM, Khem Raj <raj.khem at gmail.com> wrote:
> >> > On Wed, Sep 5, 2018 at 7:45 AM Richard Purdie
> >> > <richard.purdie at linuxfoundation.org> wrote:
> >> >>
> >> >> On Wed, 2018-09-05 at 10:53 +0200, Martin Jansa wrote:
> >> >> > But patching the components to use libssl10 might actually work
> >> >> > (unlike
> >> >> > just changing DEPENDS to openssl10).
> >> >> >
> >> >> > It's not only conflicting in build-time in RSS, but it will conflict
> >> >> > on target as well. You either need to migrate all components included
> >> >> > in image to 1.1 or all stay on 1.0.
> >> >>
> >> >> That isn't quite the case. For OE-Core we have images using both 1.0
> >> >> (openssh) and 1.1 installed together. Its true there are some issues if
> >> >> you try and parallel install both the -dev packages but normal target
> >> >> images are working.
> >> >>
> >> >> We could probably "fix" the -dev images to an extent by making 1.1
> >> >> replace 1.0 dev pieces.
> >> >>
> >> >> The build time sysroot problem is harder unfortunately, I've ideas
> >> >> about things we might be able to do but haven't experimented as yet.
> >> >>
> >> >
> >> > If runtime conflicts are clear
> >>
> >> I don't think the runtime issues are clear.
> >>
> >> Being able to install both versions of openssl on the target and have
> >> them be used by different applications is one case (already solved by
> >> different sonames).
> >>
> >> But the builds that are failing in meta-oe are a different case - a
> >> single application is indirectly linked against both versions of
> >> openssl. Loading two versions of openssl into the same address space
> >> at runtime hasn't been solved... and may not be realistically solvable
> >> - e.g. what happens if code in an app compiled against openssl 1.1
> >> tries to share an openssl data type with code in a library compiled
> >> against openssl 1.0?
> >>
>
> Any further comments?
>
> How are the meta-oe world builds looking now after the recent fixes?
> Are there still issues?