[lsb-discuss] In the "new" world

Robert Schweikert rjschwei at suse.com
Tue Apr 1 18:13:53 UTC 2014


Hi,

On 04/01/2014 10:59 AM, R P Herrold wrote:
> On Mon, 31 Mar 2014, Robert Schweikert wrote:
>
>> I know this is reaching a bit as we have not published the meeting minutes
>> from the f2f last week. I did post a high level summary to the wiki
>> (https://wiki.linuxfoundation.org/en/LSB_Plenary_2014#Meeting_Minutes)
>
> I know there is the IRC transcript, and some additional
> minutes by others what might profitably be merged as well.  No
> doubt we will discuss such at tomorrow's call (alert to Jeff
> as to an agenda item, for both a Collab meeting debrief, and
> as to possibly adding more formal documentation of the event
> outcomes)
>
>> A second example is distribution identification, i.e.
>> http://www.freedesktop.org/software/systemd/man/os-release.html ,
>> this AFAIK is currently not in the standard but is
>>
>> a.) relatively simple to sum up in a problem statement and a solution plus
>> test
>>
>> and
>>
>> b.) should not be very controversial
>>
>> On the other hand it is already on freedesktop.org.
>
> I am unclear as to the last 'it' pronoun ... I think the
> 'standard documentation' part is at freedesktop.org,

Yes, the doc is at freedesktop.org and would remain their. Let me flesh 
this out with the example LSB specification, following the new template 
in the pull request found here: 
https://github.com/LinuxStandardBase/lsb/pull/1

""""""
Problem Statement:

At times it is necessary for ISVs or software components to determine 
the underlying distribution. ISVs may choose to not install or issue 
statements about supported configurations based on the identified 
distribution.

Solution:

Adopt the freedesktop.org /etc/os-release distribution identification 
mechanism.

http://www.freedesktop.org/software/systemd/man/os-release.html

Solution discussion links:

openSUSEFactory-ML
.......

Distribution Support:
openSUSE 13.1 and later
SUSE Linux Enterprise 12 and later
Fedora XXX and later
.......

Verification Test:

tests/distro/distroID.py
"""""

> but a
> test interface is not.

Yup, such with this the os-release file would become part of the LSB and 
we'd have a test. The distributions in the document are expected to be 
"compliant" and pledge to integrate this test into their test suit. 
Whether this hapens directly or via some other testing project is 
immaterial.

> We have often seen this with
> 'incorporated' third party 'standards' documentation, with the
> testing tools over at LSB code space
>
> We have discussed in the IRC channel from time to time, and I
> think I have an open bug to start a formal process of
> 'mirroring' into an archive under LSB maintenance, remote
> standards statements.

The mirroring would no longer apply as we will no longer produce a 
"formal" specification as we do today.

> We have been burned a few times, when
> linkrot has caused some holes in our 'upstream' references

With everything in text format it will be easy for us to write a tool 
that scans all files in the documents directory and verifies that links 
are still valid. If a link is no longer reachable an e-mail is sent to 
the lsb list alerting us of the problem.

"no longer reachable" would be 3 times in a row if we run the test 
weekly. This should avoid short time transient failures and false 
positives. I made up the numbers and am not particularly attached to the 
time frame, but something in this direction should work reasonably well.

Later,
Robert

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


More information about the lsb-discuss mailing list