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

[Mark Hatle]

On 4/7/17 8:18 AM, Alexander Kanavin 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.

Ahh see in this case, APIs are changing to critical components.  In the past
we've talked about OpenSSL upgrades.  Since the world is not yet ready for the
API switch on OpenSSL.  LSB is the least of your concern there.  (I don't see
this as an LSB concern, other then it's a major component with a new API.)

In this case, we likely will need to maintain (my guess probably around a year)
both the latest 1.0.x version and the 1.1.x version.  Since 1.1.x is not a long
term stable release, and 1.0.x is, this shouldn't be very time consuming.

> 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.

Qt4 isn't part of oe-core, and in previous discussions we agreed that any LSB
support/maintenance in oe-core would ignore Qt4, other then it would attempt to
keep it as an optional component.  Key word is 'attempt'.

You have to understand that LSB is a set of filesystem, ABI/Library
compatibilities for certain things.  Very few real-world applications require
the entire LSB to be conformed to.  So doing this as a set of "this works, this
doesn't, you can enable this" is really all that is needed for real-world behavior.

The CGL specification is a good example of this.  It requires the basic LSB to
be conformed to, but only the parts that it cares about.  Initially this is the
'core', but LSB in 5.0 moved QT4 to the core.  There is a pending change in the
'next' CGL to clarify that the Qt components were never intended to be required.

Every other LSB project I've been involved with in the past 10 years has had the
same type of requirements.  Is your filesystem right, do you pass the posix
tests, do the basic APIs work as expected?  Everything else can be documented
and then ignored.  If someone needs something that falls under 'everything else'
then it is up to them to produce the missing pieces.

> 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.

Then again, release note/document in the code.  "mailx is not supported unless
you select OpenSSL 1.0.x".  Yes the exception list will grow over time, but
unless one of those exceptions is actually needed, nobody is going to care.

(In the case of mailx specifically, I expect either someone [outside the oe
community] will port it forward to the new OpenSSL, or will replace it with a
script or command that has the same arguments but uses newer tooling.)

The LSB requires certain command line components to exist, but doesn't require
anything to do with how they are implemented.  Often alternatives are or have
been created to resolve these types of issues.


So my recommendation is:

1) Document a component is no longer available in OE-Core, and how to externally
address it [if possible].

2) For things that may be part of the core and may need a replacement.  Open a
defect.  If nobody resolves that defect, then clearly it wasn't important.


OpenSSL API change to me is a different topic.  It may be driving some of the
other issue you are speaking of, but it really is a broader topic then LSB.

--Mark

> Alex
>