[Openembedded-architecture] LSB is dead; when shall we drop it?

Mark Hatle mark.hatle at windriver.com
Fri Apr 7 13:55:52 UTC 2017


On 4/7/17 8:29 AM, Otavio Salvador wrote:
> 
> 
> On Fri, Apr 7, 2017 at 10:18 AM, Alexander Kanavin
> <alexander.kanavin at linux.intel.com <mailto:alexander.kanavin at linux.intel.com>>
> wrote:
> 
>     On 04/07/2017 04:07 PM, Mark Hatle wrote:
> 
>         (Really making sure this keeps working should not be more then a day or
>         so work
>         over the course of every stable release.  If it is, we need to
>         understand what
>         is causing this work.)
> 
> 
>     I trust you do understand the concept of "bit rot" and the maintenance
>     overhead it's causing? Here's a specific example: this week day I was
>     introducing openssl 1.1 into oe-core, and checking a dozen recipes that are
>     not compatible with it by hand to see what, if anything, they are doing
>     about it.
> 
>     Qt4 is one such component, and it's pretty clear it will never be compatible
>     with openssl 1.1. So I ended up disabling ssl support in Qt4 - which was
>     thankfully not difficult to do, but is a regression in Qt4 API we provide. I
>     expect Qt4 will continue to be a source of similar issues in the future as
>     we move on with the times in oe-core, and at some point there will be an
>     issue that is not easy to resolve without disabling Qt4 altogether.
> 
>     Another LSB-mandated component is mailx, which is also dead upstream, and
>     requires openssl 1.0. When openssl 1.0 becomes unsupported at the end of
>     2019, what are we supposed to do? Not clear to me now.
> 
> 
> The main question here is if we are going to keep OpenSSL 1.0 and 1.1 in
> parallel inside OE-Core or not. For Pyro I think we should stay on 1.0 or have
> 1.1 as an opt-in option, but for 2.4 I would say to drop 1.0 if possible and
> move 1.0 to a layer ... potentially, lsb support could be moved to a layer as we
> did with gplv2 and qt4. 

OpenSSL in the upcoming Spring stable needs to 1.0.x (with an optional 1.1.x if
someone really feels strongly on this) because the rest of the system software
simply isn't ready.

For the Fall release, I say we plan for both 1.0.x and 1.1.x.  I honestly don't
believe that the general community will upgrade everything that we consider
basic (oe-core) to a system by that point.

Next Spring is likely the first time that 1.0.x COULD be dropped, but even then
I'd be doubtful.

Next Fall is where I think the likelihood of being able to finally drop the
1.0.x support will occur.  (This should be a good intersection point for the
1.1.x FIPS modules, which is holder other distros back... Various desktop
distributions will have time to move forward on this... etc...)

--Mark

> -- 
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750




More information about the Openembedded-architecture mailing list