[lsb-discuss] Thoughts on LSB ISO standard

keld at keldix.com keld at keldix.com
Wed Jul 25 18:04:17 UTC 2012

On Wed, Jul 25, 2012 at 12:34:19PM -0400, Carlos O'Donell wrote:
> On 7/25/2012 12:07 PM, Wichmann, Mats D wrote:
> > I wanted to updated on a number of the topics that have been raised
> > in the recent calls on this topic. For the last few years, since the
> > departure from the project of Nick Stoughton, I have served as the
> > editor of the LSB specification (and I was present at the Singapore
> > meeting in which the LSB submission to ISO was finalized). As
> > noted in the call I am finding it hard to continue that role and will
> > probably have to transition it to another editor.
> Thank you for your continued effort, I appreciate the work you've put
> into this over the years, and I have used the LSB specification as a
> reference point to educate and train *other* developers who had question
> about system layout etc.
> > LSB 3.1 "core" was agreed as an ISO standard, ISO/IEC 23360.1:2006
> > essentially seven years ago (it was actually 3.1, not 3.0 as some have
> > indicated).  At the same time LSB was in the process of adding a
> > very large section of functionality which ended up known as "LSB desktop".
> > Since that work was brand new and was taking place as the LSB ISO
> > effort was in progress, it does make sense that part was not included
> > in that submission, but several national bodies to ISO indicated that they
> > felt it was important to continue to evolve the standard and bring these
> > elements in as well.  Unfortunately, this evolution never happened.

Well maybe we can do that evolution now.

> > Logistically, the sponsor of the LSB project, the Linux Foundation, became
> > an ISO PAS submitter to facilitate the process.  It is my understanding
> > that this status on behalf of LF has been allowed to lapse.  LF as a
> > not for profit foundation was well positioned to sponsor the work, but
> > the sponsors of LF itself have apparently lost interest in supporting
> > the work of LSB as an ISO standard.  This is an outsider's viewpoint, I
> > cannot presume to speak for Linux Foundation, but I believe it to be accurate.

What I have heard is that LF lost their PAS submitter's status, as it was not renewed.
I am not aware of LF's intentions on renewing their status, but we could
investigate it. 

There are other ways of proceeding if LF do not want to pursue it.

1. Every member body of ISO can take any specification and
submut it as a fast-track. I am quite sure I can make Danish Standards
do so. Danish Standards have done so before. 
Also that procedure has been done recently for Ruby by the Japanese member body.

2. We could take LSB as a project in SC22.  This is how it is done by eg.
POSIX, C and C++. We need either to have a Working Group in SC22, or
some representatives from SC22 to LSB, as SC22 also do it for POSIX.

3. there are other possibilities, a bit more hairy and non-straightforward
that could be investigated should the above possibilities not work out.

The fast-track and the internal development each has its advantages and
problems, and it also depends on the various parties to the process 
which one to chose. I would say LF has the serving rights.
I can elaborate on those alternate paths if you wish.

> > There was some considerable work to make LSB core able to be
> > produced as a standard that minimally fit ISO requirements, which
> > was largely done by a contractor retained for that purpose (Nick).  That work
> > has not been lost, however we were also led to understand that we
> > were kind of given a pass in not completely conforming to the ISO
> > conventions as a first-time PAS submission, but that a future revision
> > would require additional work to more fully conform, so it may be that
> > the existing facilities to generate a specification for consumption by
> > ISO would not be sufficient - we would need advice on that issue. We
> > have tried to maintain the policy of a "common standard" - to not intentionally
> > diverge the standards wording between ISO and non-ISO. Issues that
> > specifically related to the "ISO portion" of LSB continue to have flags
> > in the LSB issue tracking system.

Good to know that the facilities are still there.

yes you have some allowance for the first PAS submission.
However there are precedence on PAS submitters not fully conforming to
the ISO dircetives for their 2nd edition of the PAS (ODF).
OTOH it would be nice if the LSB text and the ISO text are as similar as possible.
This was achieved for the POSIX standard - which in nature is not so different from LSB, I think,
so it might also be possible for us.

> > There have been three significant revisions of LSB since the ISO submission.
> > Those have been LSB 3.2, 4.0 and 4.1.  These revisions have maintained
> > the document structure that was in place when LSB 3.1 went into ISO
> > with very little change.  There has been one technical addition to core,
> > we could discuss that separately - in theory updating the "ISO LSB"
> > to LSB 4.1 level would not be a complicated process.

Sounds good.

> > However, there are two pending issues to keep in mind:
> > 
> > - LSB has often been criticised for not covering enough of Linux "common"
> > functionality; since LSB-core is a subset of full LSB, that question should
> > be even larger for whether LSB-core is actually useful as an ISO standard.
> > At the same time, there has also been the very real debate about whether
> > an LSB specification which includes "desktop" elements is an appropriate
> > requirement for server-oriented installations of LSB.

My personal opinion is that it would be good to also cover desktop elements.
We do not need to follow POSIX scope. We are on top of POSIX anyway.

> Isn't this is a question that the LSB itself has to already answer for certification?
> I would imagine that the ISO document would follow an already established answer.

If the LSB standard already has an established scope including desktop,
the the ISO version also should have that scope, IMHO.

> For example the ISO LSB could be lsb-core, with all other functionality grouped
> into optional Annexes.
> Alternatively you could publish multiple documents one for each part of the LSB
> and make them different standard. This is the approach taken by some of the
> functional safety standards like 

the 27000 series?

yes, that would also be possible. But I would like LSB to be as consistent between 
the versions as possible. Inconsistencies between versions will only confuse the marketplace.

> > - Some fairly substantial rearrangement of the LSB specfication is proposed
> > (and in fact, agreed) for LSB 5.0, which is in development now and
> > anticipated for the earlier part of 2013.  The comments about the unbroken
> > line from LSB 3.1 -> LSB 4.1 will no longer apply for LSB 5.0.
> I don't have enough background yet to know what's going into LSB 5.0, but
> this sounds like good news.
> I don't see why we need an unbroken line across the standards... other than
> that would facilitate the maintenance of the macros that built the ISO
> document.

There is no need to retain structure between different editions of a standard.
We have a prominent example of standards restructuring, namely POSIX.
There was a POSIX-1 and POSIX-2 and more, and they were combined into one part, with
different structure. Also ISO 10646 (Unicode) restructured.

Best regards

More information about the lsb-discuss mailing list