[lsb-discuss] [Lsb-infrastructure] LSB 3.1 Update 1 status (and minutesfor2/20 and 2/27)

Vladimir Rubanov vrub at ispras.ru
Sat Mar 3 05:15:23 PST 2007

Thanks, Mats, for clarification. So as far as I have understood - "Optional
LSB Module" = "Candidate Module for future LSB versions". And it does not
affect current certification at all. The approach of preparing candidate
modules in advance is of course good, I was just misled by the term


> -----Original Message-----
> From: Wichmann, Mats D [mailto:mats.d.wichmann at intel.com]
> Sent: Friday, March 02, 2007 8:22 PM
> To: Vladimir Rubanov; Ian Murdock; lsb-discuss; lsb-infrastructure
> Subject: RE: [Lsb-infrastructure] LSB 3.1 Update 1 status (and
> minutesfor2/20 and 2/27)
> Vladimir Rubanov wrote:
> > Could anyone please describe what optional LSB module mean in terms of
> > certification? Well, it is clear that we have specification
> > and tests for optional modules. It is also clear that if an
> > implementation does not support functionality from an optional
> > module it is OK for certification. But what if it does support
> > the functionality from an optional module? Do we require that
> > it should behave as in LSB in this case (i.e. do we require
> > passing the tests for optional modules for those distributions
> > that support them)? What is the sense in writing specification
> > and creating tests for optional modules in case we do not
> > require anything about them?
> you've put your finger on what has always been the issue
> with anything "optional" in LSB - what does it mean for
> people?
> Ian's crafted the current message there but essentially
> it's best to look at optional modules as something which
> clearly *will* meet our Best Practice criteria but does
> not yet, usually because it's too early or out of cycle
> for a few.  Case in point is indeed Qt4 - targeted at
> LSB 3.1 which is supposed to run on RHEL5 and SLES10,
> we were then told that RHEL5 wouldn't have the support.
> This made Qt4 an optional module, to become mandatory
> later.  Providing this specification early in the LSB
> allows people to get a look at it, and possibly even use
> it. It also allows us to get the work in and published
> while the contributor is interested - if we'd waited
> until today to start Qt4 work I'm not sure we would have
> access to the resource that did the work as he was
> foolish enough to get a promotion within TrollTech!
> Ian likes to refer to this concept as "late binding" -
> we do work as if a feature would go in, and at the last
> possible moment decide whether or not to throw the
> switch which marks it "required".
> There is no requirement on distributions; however,
> we'd *like* them to say the also support optional module
> FOO and applications using FOO would then run on that
> distribution.  In the dtk-manager context, it would
> actually have been easier if Qt4 was a separate test
> suite rather than a runtime flag to the desktop suite.

More information about the lsb-discuss mailing list