[lsb-discuss] LSB 3.2 Embedded Profile

[mats.d.wichmann@xxxxxxxxx (Wichmann, Mats D)]

Dan Kohn wrote:
> I've covered this verbally with many folks, but I'd like to officially
> propose to the list an LSB 3.2 Embedded Profile.  This is an
> additional certification profile exactly equal to LSB 3.2, except that
> no tests need be passed from the X, qt, or gtk libraries.  The only
> distributions that may be certified as LSB 3.2 Embedded are those that
> ship neither the qt nor gtk libraries.  I.e., enterprise distros need
> to pass the regular the LSB 3.2 certification.
> 
> The purpose of this new profile is for Carrier Grade Linux
> distributions, which are required to pass the LSB as part of
> registering as CGL 4.0 compliant.  Otherwise, they are forced to
> register under LSB 3.0, which is the last version of the LSB without
> the graphics libraries.  The LF would like to only have to actively
> maintain the LSB 3.2 test infrastructure, plus the LSB 4.0 tools
> currently under development.  Plus, there were a significant number of
> bugs fixed between LSB 3.0 and LSB 3.2, and 3.2 is able to make use of
> the dramatic improvement in test infrastructure.
> 
> For now, LSB 3.2 Embedded Profile Certifications can use the existing
> Distribution Testkit Manager, and just request waivers on all
> graphical libraries.  In the future, we'll update those tools to
> choose between 3.2 regular and 3.2 Embedded Certification.  The LF is
> also very open to creating new profiles to match up to the libraries
> in the current mobile initiatives, including LiMo, Android, and
> Moblin.

Tech stuff:

It's part of the way there now:  you can currently choose between
"Core & C++" and "Core & C++ & Desktop" on some of the tests; you
cannot, however, make this choice overall. Making the choice
overall should eliminate the Desktop, Desktop-T2C, and X11 tests.

We have three things now that don't naturally fit one place or
the other: Perl, Python and Printing (each of these have a test
suite which is run in a full certification run currently).
Which profile should these be part of? This choice may also
affect the implementation of libchk and cmdchk.

We would also need to decide the set of application battery
elements which is required for this "embedded" profile.