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

[Martin Jansa]

On Wed, Sep 05, 2018 at 09:14:21AM +0200, Alexander Kanavin wrote:
> I am also disappointed to see that openssl10 does not help much,
> however, I do not believe we should wait another year, and hope the
> problem would take care of itself - this clearly did not happen over
> the past year. Let's just look at failing recipes one by one and
> investigate what needs to be done for them. I've done this for
> everything in oe-core, and so it does not need openssl10 anymore
> (except one issue with openssh on arm64). It might be that much of the
> failing stuff is simply out of date.

Here is the thread from last year with a bit more details:
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg100353.html

oe-core is just very small core, fixing it there doesn't prove anything

> Making 1.0 and 1.0 coexist in a sysroot means one of them has to be
> renamed into, say, libssl10.so, and everything that is using it
> patched accordingly. Not really possible. Yes, upstream has botched
> this transition badly. If you have better ideas, let me know please.

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.

The 15 failures I've mentioned before were all in our internal
components (e.g. whole nodejs-* world is botched if you use openssl10 in
nodejs DEPENDS).

In a bit smaller world builds than what Khem is now testing I'm seeing
also around 40 recipes failing (and nobody knows how many are "hidding"
behind them).

I'm not against openssl-1.1 upgrade when it's ready, but saying in
commit message that incompatibilities are easily solved by using
openssl10 in DEPENDS just isn't true as proven a year ago and it still
isn't.

Regards,

> 2018-09-05 6:54 GMT+02:00 Khem Raj <raj.khem at gmail.com>:
> > On Tue, Sep 4, 2018 at 9:08 PM Andre McCurdy <armccurdy at gmail.com> wrote:
> >>
> >> On Tue, Sep 4, 2018 at 6:49 PM, Khem Raj <raj.khem at gmail.com> wrote:
> >> > On Tue, Sep 4, 2018 at 3:58 PM <richard.purdie at linuxfoundation.org> wrote:
> >> >>
> >> >> On Tue, 2018-09-04 at 13:43 -0700, Khem Raj wrote:
> >> >> > I pointed this earlier before merge as well
> >> >> > meta-openembedded has 40 odd recipes failing due to openssl 1.1
> >> >> > upgrade
> >> >>
> >> >> Sorry, I think I missed something somewhere as I thought the
> >> >> indications were the bigger problems like qt5 were working now :/.
> >> >>
> >> >> > http://errors.yoctoproject.org/Errors/Build/67457/?page=2&limit=50
> >> >> >
> >> >> > so obvious fix was to keep them pinned to openssl10 and i created
> >> >> > couple of fixes
> >> >> > to start
> >> >> >
> >> >> > https://patchwork.openembedded.org/patch/154517/
> >> >> > https://patchwork.openembedded.org/patch/154516/
> >> >> >
> >> >> > and the effects are showing up where sysroot task now starts to fail
> >> >> > for dependent
> >> >> > recipes here
> >> >> >
> >> >> > http://errors.yoctoproject.org/Errors/Details/190427/
> >> >> > http://errors.yoctoproject.org/Errors/Details/190433/
> >> >> >
> >> >> > in meta-oe certain recipes can be upgraded and we can get openssl 1.1
> >> >> > support
> >> >> > but others like the two examples I cited above do not have openSSL
> >> >> > 1.1 port.
> >> >> > so I think we can not live without openSSL 1.0 and OpenSSL 2.0 being
> >> >> > able to
> >> >> > co-exist.
> >> >>
> >> >> The latter link is php 7.2 which should have openssl 1.1 support
> >> >> (https://bugs.php.net/bug.php?id=72360).
> >> >>
> >> >> For the former, libgdata doesn't have an openssl depends so I guessed
> >> >> at liboauth pulling it in which does have an openssl 1.1 patch at:
> >> >> https://github.com/x42/liboauth/issues/9
> >> >>
> >> >
> >> > Thanks for pointers and they do help. However IMO the problem that
> >> > Martin decribed
> >> > is going to be a real blocker. Unless we can provide a solution to let
> >> > both openssl versions
> >> > coexist, this change is going to be problematic since we maintain
> >> > several old recipes which
> >> > would have to be fixed for openssl 1.1 and this can take time, right
> >> > now we are only seeing
> >> > meta-openembedded layers, we don't even know all other layers which
> >> > might get into similar
> >> > issues.
> >>
> >> To be clear, the issue is ( foo depends on openssl 1.1 and bar ) and (
> >> bar depends on openssl 1.0 ), right?
> >
> > yes.
> >
> >>
> >> Anyway, just for reference, it looks like Debian is packaging both
> >> openssl 1.0 and 1.1:
> >>
> >>   https://packages.debian.org/source/sid/openssl1.0
> >>   https://packages.debian.org/source/sid/openssl
> >>
> >> In the case of liboauth, they avoid to need to patch by configuring
> >> liboauth to build with nss instead of openssl.
> >
> > this is already taken care see
> > http://git.openembedded.org/meta-openembedded-contrib/commit/?h=kraj/master&id=b1f87edc4202d6238c469dde358819c534b35751
> >
> > but thats just one case.
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180905/91423845/attachment-0002.sig>