[lsb-discuss] Can we find a fit for LSB and Mobile?

Robert Schweikert rjschwei at suse.com
Fri Apr 13 18:05:38 UTC 2012


I'll bite. Part of this discussion was started in another thread, and as 
Mats pointed out this needs to be in it's own thread, so here it goes.

In the past we've had passionate discussions about "splintering" the 
LSB. Most of these were started when we talked about "profiles" or 
"modularization". Low and behold we are talking about modularization 
again with a plan to move forward with this effort, and sure enough the 
mobile stuff pops up again ;) .

With this out of the way lets get to the point, I'll make some 
proclamations first and then come back to provide commentary.

1.) With modularization we are NOT changing what it means to be LSB 
   ~ This means, a distribution that wants to be LSB certified must
     provide all LSB Modules and Submodules according to the

2.) The LSB needs to remain a trailing standard that is relatively slow 


1.) In previous discussions we have always been very mindful about the 
"dangers" of splintering the LSB into multiple certification/compliance 
standards. It is my strong believe that we need to continue to be 
mindful about this. A compliance/certification line of "Certified to 
LSB-Core" would IMHO not work in favor of the LSB. As far as 
certification is concerned we need to treat the LSB as a whole. From the 
distribution point of view this requires that a certified distribution 
has to provide all modules and submodules according to the written 
specification. From an application point of view this implies that an 
app that is LSB certified can use any or all of the modules and 
submodules provided by the LSB specification. Therefore, we maintain the 
same generality with modularization that we have today without 
modularization. Providing subsets of compliance/certification would 
break this generality.

This is not to say that there might not be other compliance programs, 
the Meego compliance program comes to mind. The key here is that LSB is 
LSB. If parts of the LSB (specification, tools, tests, whatever) can be 
re-used for other purposes, great, but these other purposes should be 
clearly delineated in puprpose and name. If I provide a distribution 
that only provides support for C, C++, no GUI or other stuff then I 
cannot be certified to the LSB, so be it. If there is a "Mini-Linux" 
compliance program that only requires C and C++ support from a runtime 
perspective than I can certify to "Mini-Linux", that's it. Whether or 
not the "Mini-Linux" certification program is then based on LSB-Core or 
not is immaterial, "Mini-Linux" would be it's own stand alone 
certification/compliance program.

2.) One of the core charters, at least for as long as I have been 
involved in the LSB, was to attempt to provide an environment that is 
targeted towards the Enterprise market. This is probably not documented 
anywhere, but this is the paradigm we have been following by the actions 
we have taken and the specifications that have been released.  Although 
we have made a deliberate decision to be a bit more forward looking than 
in the past, we are still looking at "what do we anticipate in the next 
enterprise distro releases". Therefore, we will by definition always be 
quite a ways off the leading edge. So far the Mobile market has had a 
much narrower gap to the leading edge than the LSB. While the more 
forward looking approach for LSB 5 may narrow this gap we will not reach 
the point where we will catch up to the versions of software used in 
Mobile devices. I would say that by the time LSB 5.0 is released there 
will be work going on for mobile devices that targets Qt5, and Qt5 is 
not even on the radar for LSB 5.0. Keeping this in mind there may not be 
a good match to begin with.

Anyway, to sum things up. IMHO LSB and Mobile do not mix very well by 
definition. This is not to say there cannot be other compliance programs 
that use some of the work we do in LSB, but these should not be called 
LSB. Also, the whole thing really has nothing to do with modularization.


Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei at suse.com
rschweik at ca.ibm.com

More information about the lsb-discuss mailing list