For 2.2 we should review the LSB 5 compliance and ideally move to version 5. This includes dropping Qt3.
Maybe it makes sense to remove lsb from OE and move it to its own layer.
Here are the release notes for LSB5: https://wiki.linuxfoundation.org/en/ReleaseNotes50 They have removed Qt3 (and almost sorta apologize for it, because it breaks the all-important backwards compatibility!). They have also added mandatory requirements for SANE (yes, the flatbed scanner framework), libncursesw, libtiff, libxslt. A bunch of other things have been updated: - Many GTK+ library dependencies have been updated to 2.32, and the support needed for GTK+/GDK 3.0 is available, although resident in the trial use module in this release. - Cairo has been updated to 1.30. - OpenGL has been updated to the 2.1 API. - The XCB API for X11 has been added. Then we'd also need to check the spec for .so versions and verify that they match against what oe-core provides, and also update lsb's utilities and test scripts and other things. Meanwhile, Debian and Ubuntu have abandoned LSB support entirely about 9 months ago: https://lwn.net/Articles/658809/ Choice quote: "The crux of the issue is, I think, whether this whole game is worth the work: I am yet to hear about software distribution happening through LSB packages. There are only _8_ applications by 6 companies on the LSB certified applications list, of which only one is against LSB >= 4. " I don't know for certain if creating a separate layer is technically feasible, but even that work should happen only if someone will continue to maintain that layer. Otherwise, let's just remove lsb bits for good.
Alaxander, Thanks for the information. LSB is one of the items on a check list for customers. MV is has to be LSB compliant. LSB is also a requirement for CGL, (lsb 3 IIRC). CGL is also an item on a check list. Just like Yocto compatibility is an item on a check list. The number of companies needing it are small IMHO. Having LSB in a separate layer may be a good fit for this addressing LSB 5. MV will certainly need LSB for the forcible future so I don't mind maintaining that layer.
To be honest, you should seriously challenge that check list with your customers. Is it a real requirement that gets utilized in their production work, or is it merely a very old item on the list that no one remembers the reasons for why it's there and so isn't able to take it off the list?
(In reply to comment #4) > To be honest, you should seriously challenge that check list with your > customers. > it does not matter, it somewhat Marketing/Sales driven. LSB CGL Yocto Windriver X X X Enea X X X MV X Mentor X X X Ok, we can drop MV from our short list. > Is it a real requirement that gets utilized in their production work, Some do, some don't. or is > it merely a very old item on the list that no one remembers the reasons for > why it's there and so isn't able to take it off the list? Hard to say.
re-assigning to self per IRC.
WR just sent a patch to "sort of" move to LSB5.
Ross, can this be resolved as fixed now, so I can resolve #8044?
Effectively fixed with oe-core 89771f2. Compliance is not 100% and thanks to more dependencies in v5, worse than it was with v4.