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

[Andre McCurdy]

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?

> I think we can install the headers into /usr/include/openssl10/
> and dev libs into /usr/lib/openssl10
> and provide a openssl10.pc file to we can use pkgconfig in packages