[lsb-discuss] Can we find a fit for LSB and Mobile?
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
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
rjschwei at suse.com
rschweik at ca.ibm.com
More information about the lsb-discuss